This is the mail archive of the
mailing list for the Cygwin project.
Re: new policy for packages
- From: "Gareth Pearce" <tilps at hotmail dot com>
- To: <cygwin-apps at sources dot redhat dot com>
- Date: Fri, 11 Jan 2002 22:19:08 +1100
- Subject: Re: new policy for packages
- References: <079301c19a87$404969a0$0200a8c0@lifelesswks>
----- Original Message -----
From: "Robert Collins" <email@example.com>
Sent: Friday, January 11, 2002 9:03 PM
Subject: new policy for packages
> I want to suggest that the following become policy:
> No new packages are accepted that require non-packaged prerequisites.
> i.e. using rpm which was raised on cygwin@ recently,
> until db 3.2 is packaged and maintained by 'someone', rpm is not
> acceptable as a package.
This makes sense to me - however I was wondering to what extent.
1. no packages which have run-time dependencies on non-packaged.
2. no packages which have Build time dependencies on non-packaged during
3. as 2 but even if the code distributes an 'internal' copy.
4. no packages which can have build time dependencies on non-packaged with
an additional configure flag or similar.
1. seems a relatively obvious requirement ... but postgresSQL doesnt follow
it by the sounds of things.
2. is what I would think best at first - but
3. would drive people towards seting up fuller library support basis then we
have at the moment? Also since the library might need cygwin specific
patches - avoids 5 different packages with different levels of problems
because of different levels of successful patching of the included
4. seems way over the top to me ... so I didnt put anything stricter in my
list. But maybe someone out there would think this good. (mainly cause
nano fails this one :P - it can be built with slang by configure option - a
few other things too i think)
Another requirement consideration - which I am unsure if would be wanted -
but thought I might put it up for discussion.
All 'library' style packages must provide dynamic link libraries (if
I was considering looking at packaging up slang or a few other things - but
thought that not providing dynamic libs would be the wrong move to take, and
due to lack of experience in making 'good' dynamic libraries on my behalf -
decided I would put it off, (prehaps hoping someone else would do it)
my pi/2 cents (rounded).