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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Subject: RE: /setup.html please read From: Robert Collins To: "Roth, Kevin P." Cc: cygwin-apps AT cygwin DOT com In-Reply-To: <6EB31774D39507408D04392F40A10B2BC1FDBD AT FDYEXC202 DOT mgroupnet DOT com> References: <6EB31774D39507408D04392F40A10B2BC1FDBD AT FDYEXC202 DOT mgroupnet DOT com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1004744482.9086.59.camel@lifelesswks> Mime-Version: 1.0 X-Mailer: Evolution/0.15 (Preview Release) Date: 03 Nov 2001 10:58:45 +1100 X-OriginalArrivalTime: 03 Nov 2001 00:03:01.0417 (UTC) FILETIME=[E7274990:01C163FA] On Sat, 2001-11-03 at 04:23, Roth, Kevin P. wrote: > 1) > Under "Package File Naming", I see "The first release of a > package for a given vendor version may optionally skip the > suffix". I take that to mean that > cURL-7.9-1.tar.gz > and > cURL-7.9.tar.gz > are both acceptable? Is that true? Historically is has been. I'm in favour of requiring the -1, but I don't want things to be 'too hard'. > 2) > Under "Making Packages", I think the "standard" for binary > packages is to leave off the initial "/" on filenames Correct. Thank you. > 3) file -> directory typo Thanks > 4) > The oft-referenced texinfo-4.0 example on the cygwin ml > includes the specific commands that can be used to > "unapply" the foo-vendor-suffix.patch file; could you > add those commands to this file? Well, those commands depend on the exact patch syntax used. I've added a set that *should* be ok. > > 5) > Again under "Making packages", you said that the patch > file should extract to /usr/src/foo-vendor-suffix.patch. > The texinfo example says it should go at > /usr/src/foo-vendor-suffix/CYGWIN-PATCHES/foo-vendor-suffix.patch. > > Which place is "correct"? Ah, I'm changing things here. I think that having it 1 level up from the patched source tree is _much_ easier, otherwise your patch really _cannot_ clean the tree properly - because it is in it. Thoughts from everyone? > 6) > Again, not to be nit-picky; however your example of > "foo-vendor-suffix" is a bit misleading. Most packages > use "package-version-suffix", and don't (necessarily) > mention the "Vendor" in the package's name. I suggest > using the more generic but hopefully more accurate > "package-version-suffix" verbage throughout the doc. Ok, I'll do this at a more relaxed time. foo-vendor-suffix came from the earlier in the article definitions - pacakge "foo", vendor version "vendor"... Rob