Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
X-Originating-IP: [211.28.149.185]
From: "Gareth Pearce" <tilps AT hotmail DOT com>
To: <cygwin-apps AT sources DOT redhat DOT com>
References: <079301c19a87$404969a0$0200a8c0 AT lifelesswks>
Subject: Re: new policy for packages
Date: Fri, 11 Jan 2002 22:19:08 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE38GpaoG1VRIjn04x20000c6a4@hotmail.com>
X-OriginalArrivalTime: 11 Jan 2002 11:19:02.0761 (UTC) FILETIME=[C619F590:01C19A91]


----- Original Message -----
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-apps AT sources DOT redhat DOT 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.
>
> 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
libraries.
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
possible?).

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).

Gareth