This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: packages that should be in the cygwin distribution but aren't


On Sat, Nov 13, 2004 at 03:08:44PM +0100, Reini Urban wrote:
>Gerrit P. Haase schrieb:
>>Christopher Faylor wrote:
>>>On Fri, Nov 12, 2004 at 11:50:19PM +0100, Gerrit P. Haase wrote:
>>>
>>>>Maybe these are not standard packages for administrators, but since you
>>>>asked for development packages, these all are basic libraries or
>>>>compilers for developers.
>>>
>>>
>>>And, yet, I'm a developer, and I don't have one of those libraries on my
>>>system.
>....
>>Anyway, I think I got your point.  I was really missing top, but today I 
>>learned that it is already part of the distribution.
>>
>>Do we have the at command? smartmontools? ntfs-progs? some watchdog?
>
>I'm looking into adding some mstask.h and ntifs.h to w32api,
>but my time is limited.
>I'd prefer far more diagnostic features for developers,
>esp. better /proc.
>Maybe hook those automounts off cygwin.dll and let mount handle that on 
>demand.

I REALLY don't understand what the confusion is here.

I was not soliciting changes to the cygwin DLL or additions to w32api.
I was not asking for someone to provide a list of random Debian
packages.

I provided a list of packages which I thought acted as an example for
what I was trying to accomplish.  I was trying to come up with a list of
missing standard *UNIX/Linux* packages.

>And some more parts of util-linux.

"some more parts of util-linux" is not specific enough to do anything.

>And some kind of port for getloadavg().
>And some hook for mount to load + unload (!) ntifs-based drivers in unix 
>fashion: ext2fs, ext3fs, procfs, romfs, swapfs, cofs, devfs, ...

There is an obvious difference between "packages that should be in the
distribution" and "getloadavg" or "ntifs-based drivers".

If you'd like to discuss "How I'd love to improve the Cygwin DLL", feel
free to start another thread.  There is no reason to hijack this one.

I had actually naively hoped that people would provide feedback along the
lines of "We're missing elm" not "I think that someone should take months
of time and develop a driver model for the Cygwin DLL".


cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]