cygipc packaging was Updated setup.ini with descriptions, categories, and dependencies

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> Ralf Habacker wrote:
> >
> > Hi,
> > has anybody thinked about the cygipc package, which is needed by
> kde ? Should
> > this be integrated and if so in which category ?
> >
>
> This has been mentioned with respect to postgresql and kde.
> Unfortunately, the answer is: "nothing we can do".  That particular
> dependency will remain "off book" (kinda like Social Security in the US
> -- it's "real", but it doesn't "count")
>
> The problem is basically that the best is the enemy of the good (or in
> this case, the merely adequate).
>
> The Right Thing To Do is to add full IPC support to cygwin itself.
> There are a few folks thinking about this issue, and what it will
> require.  Among them: a streamlined daemon starter (cygrunsrv...), a
> daemon to manage permissions and the shared objects themselves (Egor's
> "cygwin daemon"?), and *a complete rewrite of IPC code without reference
> to cygipc*.  (This has to do with licensing issues; the original authors
> of cygipc retain copyright, and seem to have disappeared -- therefore,
> we can't contact them to encourage them to assign copyright to Cygnus.

The email adress if from france. I know a french developer, to which I have
send the infos about these guys. Perhaps he can find out something.

> Ergo, the existing cygipc code can't be directly incorporated into
> Cygwin itself.  (Worse, anybody who has studied the cygipc code is
> disqualified from contributing or working on a re-implementation for
> cygwin1.dll)
>
> Now, we could just add cygipc as regular package (e.g. not part of
> cygwin1.dll).  But...
>
> then there's less pressure/desire/need to do The Right Thing.  The
> decision was made a long time ago NOT to add cygipc as a package, and to
> work toward The Right Thing.
>
> Unfortunately, progress on that front has been slow.  If someone other
> than me is willing to take over maintaining cygipc, then perhaps it is
> time to revisit that decision, and evaluate whether The Right Thing
> (adding IPC functionality to cygwin1.dll itself) is *ever* going to
> actually happen.
>
> If not, (assuming someone else will maintain it) then perhaps we should
> include cygipc as a package.

I understand this complex problem only a little and I have some additional
questions/remarks from my
subjective view:

pro packaging:
1. Which advantage has integrating cygipc into cygwin ?
For kde2 as example I have no problem to use an additional package, because it
depends
on about 15 external libs. One more or less isn't very important.
Are there performance issues, stability, maintainance or other reasons ?
What about the needed time to integrate this ? When would this be ready for use
?

pro integrating
2. Is cygipc not distributed under the GPL ? Isn't that not enough to modify
and use this code for cygwin, perhaps maintained as separate static lib,
but linked into cygwin like the cygwin xfree team thinked about for the Xextlib
?

pro integrating
3. Chris wrote:
>IIRC, the original "authors" got the code from the linux kernel
>so they couldn't actually assign anything.
What's than the problem to take this code and integrate it ? Who can made a
decision ?

As I stated before, I see this from my very subjective way and this is because
of the hard work on
porting kde, mostly with ld and libtool (which are not ready for use with kde2)
I like the cygipc as it is.
Install and run. Thats all. If someone is able to say integrating is very little
work (I can't that), than this would be the best way :-)

Are there any other meanings ?

Ralf