Thu Mar 2 04:09:00 GMT 2006
Christopher Faylor wrote:
> What problem are we trying to solve here?
> I thought that we resolved a long time ago that we were going to use
> cygutils and pull things into it from util-linux as needed.
I believe that's the current operating assumption, mainly because when I
first created cygutils (known as 'misc' at the time), I simply snarfed
most of its contents from util-linux, and hacked them up to remove the
internal references to shipped-along gettext use instead the
system-installed libintl3 instead, and various other changes.
Thus, since much of util-linux ended up in cygutils, inertia sez "keep
However, these util-linux "ports" represent a fork from the "official"
> I don't see any compelling reason to change this behavior. Am I missing
Well, the compelling reason is to un-fork. I don't track util-linux
changes -- but then, there haven't been any complaints about "why is
col.exe out of date" so far. Plus, even if you strip out all of the
apps in the OP's package that compile-but-do-not-work, you're still left
with a list bigger than what is currently available in cygutils (I think).
Two choices: "port" these (few?) additional programs to cygutils (e.g.
so they too link against installed libintl3, use #include <common.h>
which is properly autoconf-guarded instead of hard-including a bunch of
stuff, etc). Or, remove the current versions from cygutils and let the
OP take 'em.
I honestly don't care. Removing stuff from cygutils is easy; adding
stuff to cygutils -- assuming I'm handed a patch to do so -- is also
easy (for me). Creating that patch, to do the things mentioned in the
preceeding paragraph and outlined in
/usr/share/doc/cygutils-1.2.10/HOW-TO-CONTRIBUTE is a bit harder.
So, the big question here is: exactly how many new utilities are we
talking about here, that actually *work* on cygwin (rather than just
compile)? 5? 10? 1? Dunno -- the OP will have to answer that. Then
we can have a more informed discussion.
More information about the Cygwin-apps