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

- Raw text -