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
Message-ID:	<3BE2E3D3.1050201@ece.gatech.edu>
Date:	Fri, 02 Nov 2001 13:20:03 -0500
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language:	en-us
MIME-Version:	1.0
To:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC:	cygwin-apps AT cygwin DOT com
Subject:	Re: /setup.html please read - feedback desired
References:	<1004700277 DOT 7488 DOT 2 DOT camel AT lifelesswks>

Robert Collins wrote:


In the "Package file naming" section:
"In the event that a package doesn't sort correctly (for example, from 
...-9-... to ...-10-..., use the setup.hint current, prev and exp labels to 
override the inbuilt sort during the transition period."

I think setup.hint's are more-or-less required, now.  Otherwise, there's no 
way to set the sdesc, ldesc, dependencies, etc.  So, the "auto-sort" is a 
soon-to-be-vestigial feature; emphasis should be on setup.hint.

Ditto in the "setup.hint" section:
"If the above rules don't work for your package, for some reason, ..."

setup.hint should be the "normal" method, not the fallback method

"The requires line indicates the packages that this package relys on. A 
package can rely on multiple packages. Multiple packages are separated by 
spaces."
+ "Do not enclose multiple package names within quotation marks."

In section "Making packages"
"In your binary package include a file /usr/doc/foo-vendor that includes 
any binary-relevant vendor documentation, such as ChangeLog's, copyright 
licence's, README's etc."

...include a directory /usr/doc/foo-vendor...

"Include a single file foo-vendor-suffix.patch in your source package, that 
when applied will remove all the patches you've applied to the package, 
leaving it as the vendor distributes it. This file should extract as 
/usr/src/foo-vendor-suffix.patch."

This is NEW.  What if you have multiple patches (some cygwin-specific, 
others "standard patches")?  See tiff src package -- CYGWIN-PATCHES 
contains the lossless-jpeg "standard" patch, plus a cygwin-specific patch. 
  Or "old-style" ncurses (and current readline) package:  there's the 
"regular" pre-applied cygwin-specific patch, and then a second 
"dll-ization" patch applied at a particular point during the build process.

There are some problems with the "/usr/src/foo-vendor-suffix.patch" idea 
that are not easily solved.  This change should be discussed (new thread?) 
prior to unilateral declaration on setup.html...

In the "Submitting a package" section:
"Do you have a SSH1 public key? This is required to upload the packages"

See cgf's comment on unfettered access to sourceware...

"Look in the debian package list"
a link would be good, here.

"Announce on cygwin-apps AT cygwin DOT com that you have the package ready for 
uploading, and a user account and package directory will be created for you."

again, see cgf's comment

--Chuck









 
> Rob
> 
> 
> 
> 

- Raw text -