ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/09/02/07:29:02

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Subject: cygipc packaging was Updated setup.ini with descriptions, categories, and dependencies
Date: Sun, 2 Sep 2001 13:32:53 +0200
Message-ID: <000b01c133a3$0145ec10$7d6707d5@BRAMSCHE>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <3B8C2682.DE851E18@ece.gatech.edu>

> 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
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 ?


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019