This is the mail archive of the 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: new policy for packages

----- Original Message -----
From: "Robert Collins" <>
To: <>
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.
> Thoughts?

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
'standard' compile.
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).


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