Re: strange source packaging?
Can we get a diff for the HTML page? Okay --- setup-old.html Sun Apr 21 03:03:18 2002 +++ setup.html Sun Apr 21 03:01:44 2002 @@ -21,9 +21,9 @@ border=0 usemap=#topbar alt=/a/center !-- == -- -!---- -!--Left Sidebar -- -!---- +!-- -- +!--Left Sidebar -- +!-- -- table align=left border=1 cellspacing=0 cellpadding=8 width=20% bgcolor=ee trtd bgcolor=ee valign=top @@ -71,11 +71,11 @@ pThis document is intended for people who post packages to sources.redhat.com, and thus need to make them available through the -standard Cygwin setup program. This documents the syntax of the +standard Cygwin setup program. This documents the syntax of the setup.ini file, the program that automatically generates it on a regular basis, the layout required for packages, and the related policies to ensure good behaviour from the setup.exe program./p pSetup depends -on certain conventions being followed. If they are not followed, bad +on certain conventions being followed. If they are not followed, bad things may happen to the users of setup.exe. Where a convention can be ignored, should circumstances warrent, this document will specify that./p pThe mailing list [EMAIL PROTECTED] is the correct @@ -94,11 +94,11 @@ /ul h2a id=naming name=namingPackage file naming/a/h2 -p Package naming scheme: use the vendor's version plus a suffix for +p Package naming scheme: use the vendor's version plus a release suffix for ports of existing packages (i.e. bash 2.04 becomes 2.04-1, 2.04-2, etc, until bash 2.05 is ported, which would be 2.05-1, etc). Some packages also use a YYMMDD format for their versions, e.g. binutils-20010901-1.tar.bz2. -The first release of a package should have a -1 suffix./p +The first release of a package should have a -1 release suffix./p pA complete package currently consists of three files:/p ul @@ -107,18 +107,18 @@ lia setup.hint file /ul -pBinary tar files are named package-version.tar.bz2. They generally +pBinary tar files are named package-version-release.tar.bz2. They generally contain the executable files that will be installed on a user's system plus any auxilliary files needed by the package. See the a href=#package_contentsmaking packages/a section below for more details on how to generate a binary tar file./p -pSource tar files are named package-version-src.tar.bz2. Source tar files -should contain the source files needed to rebuild the package. While +pSource tar files are named package-version-release-src.tar.bz2. Source tar files +should contain the source files needed to rebuild the package. While installing these files is optional under setup.exe, the inclusion of a source tar file is part of the totality that makes up a cygwin package -and so, these files are emnot/em optional. See the a -href=#package_contents making packages/a section below for more +and so, these files are emnot/em optional. See the a +href=#srcpackage_contents making packages/a section below for more details on the contents of a -src tar file../p pThe setup.hint file is discussed a href=#setup.hintbelow/a. @@ -126,22 +126,31 @@ h2a id=sources.redhat.com name=sources.redhat.comAutomatic setup.ini generation on sources.redhat.com/a/h2 pA script runs on sources.redhat.com which collects information from -(currently) the ttlatest/tt and ttcontrib/tt directories in the +(currently) the ttrelease/tt directory in the ftp download area. Information from subdirectories of these directories is parsed to automatically generate the default a href=#setup.ini setup.ini/a file which is used by the cygwin setup.exe program for installation control. If you are responsible for maintaining a cygwin package, it is important that you understand how this process works./p -pPackages are grouped by directory under ttlatest/tt or -ttcontrib/tt. The directory name is typically the same as the -package name. For example, the ttboffo/tt package will live in the -ttboffo/tt subdirectory. Exceptions to this rule are historical. -All new packages will follow the rule of package name == directory name. +pPackages are grouped by directory under ttrelease/tt. The directory +name is the same as the package name. For example, the ttboffo/tt package +will live in the ttboffo/tt subdirectory. Exceptions to this rule are +historical. All new packages will follow the rule of package name == +directory name. However, for closely related groups of packages, it is acceptable +to use a heirarchical tree under ttrelease//tt: +prett +
Re: strange source packaging?
All the content changes look great however. If you can clean up the space to tab conversion, I'm happy for this to go in. However as it's a change to the standard... Any objections from any contributor? Rob (see below for the tab occurences) === - Original Message - From: Charles Wilson [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 21, 2002 5:04 PM Subject: Re: strange source packaging? Can we get a diff for the HTML page? Okay Thanks... -standard Cygwin setup program. This documents the syntax of the +standard Cygwin setup program. This documents the syntax of the This change (not eye-visible) is wrong - Tabs have no meaning in HTML. Mind you double spaces don't mean all that much either :}. However Tabs are definately wrong. -on certain conventions being followed. If they are not followed, bad +on certain conventions being followed. If they are not followed, bad Ditto. -pSource tar files are named package-version-src.tar.bz2. Source tar files -should contain the source files needed to rebuild the package. While +pSource tar files are named package-version-release-src.tar.bz2. Source tar files +should contain the source files needed to rebuild the package. While Ditto for the second line. (What editor are you using?) -the introducing field. This usage is allowed but deprecated. Please +the introducing field. This usage is allowed but deprecated. Please And again.. -different from the name of the directory in which the package resides. This +different from the name of the directory in which the package resides. This And... here. -ttprev/tt. Otherwise, the bonly/b version that setup.exe will +ttprev/tt. Otherwise, the bonly/b version that setup.exe will Guess what.. :}. -above. Uses arrow keys for positioning over moles. Space +above. Uses arrow keys for positioning over moles. Space I've included all these for completeness, not to be a pain. They need to get fixed before committing. -word. We don't anticipate that this will change anytime soon. However, +word. We don't anticipate that this will change anytime soon. However, Another. -This line follows the setup-timestamp in all setupl.ini files. It +This line follows the setup-timestamp in all setupl.ini files. It Guess what. -This is the long description of the package. This text, if +This is the long description of the package. This text, if And... -One package can belong to multiple categories. Multiple categories are +One package can belong to multiple categories. Multiple categories are Some more. -The requires line indicates the packages that this package belongs to. A -package can rely on multiple packages. Multiple packages are separated +The requires line indicates the packages that this package belongs to. A +package can rely on multiple packages. Multiple packages are separated Hmm.. :} -run is not guaranteed. Therefore, if your package depends on others +run is not guaranteed. Therefore, if your package depends on others Finally whew Rob
Re: strange source packaging?
Robert Collins wrote: All the content changes look great however. If you can clean up the space to tab conversion, I'm happy for this to go in. However as it's a change to the standard... Any objections from any contributor? Okay, I've made the corrections you mentioned. I had smart tabs on earlier. Oops. The newly modified setup is here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/setup.html --Chuck --- setup-old.html Sun Apr 21 22:45:52 2002 +++ setup.html Sun Apr 21 22:57:14 2002 -22,7 +22,7 !-- == -- !---- -!--Left Sidebar -- +!-- Left Sidebar -- !---- table align=left border=1 cellspacing=0 cellpadding=8 width=20% bgcolor=ee -94,11 +94,11 /ul h2a id=naming name=namingPackage file naming/a/h2 -p Package naming scheme: use the vendor's version plus a suffix for +p Package naming scheme: use the vendor's version plus a release suffix for ports of existing packages (i.e. bash 2.04 becomes 2.04-1, 2.04-2, etc, until bash 2.05 is ported, which would be 2.05-1, etc). Some packages also use a YYMMDD format for their versions, e.g. binutils-20010901-1.tar.bz2. -The first release of a package should have a -1 suffix./p +The first release of a package should have a -1 release suffix./p pA complete package currently consists of three files:/p ul -107,18 +107,18 lia setup.hint file /ul -pBinary tar files are named package-version.tar.bz2. They generally +pBinary tar files are named package-version-release.tar.bz2. They generally contain the executable files that will be installed on a user's system plus any auxilliary files needed by the package. See the a href=#package_contentsmaking packages/a section below for more details on how to generate a binary tar file./p -pSource tar files are named package-version-src.tar.bz2. Source tar files +pSource tar files are named package-version-release-src.tar.bz2. Source tar files should contain the source files needed to rebuild the package. While installing these files is optional under setup.exe, the inclusion of a source tar file is part of the totality that makes up a cygwin package and so, these files are emnot/em optional. See the a -href=#package_contents making packages/a section below for more +href=#srcpackage_contents making packages/a section below for more details on the contents of a -src tar file../p pThe setup.hint file is discussed a href=#setup.hintbelow/a. -126,22 +126,31 h2a id=sources.redhat.com name=sources.redhat.comAutomatic setup.ini generation on sources.redhat.com/a/h2 pA script runs on sources.redhat.com which collects information from -(currently) the ttlatest/tt and ttcontrib/tt directories in the +(currently) the ttrelease/tt directory in the ftp download area. Information from subdirectories of these directories is parsed to automatically generate the default a href=#setup.ini setup.ini/a file which is used by the cygwin setup.exe program for installation control. If you are responsible for maintaining a cygwin package, it is important that you understand how this process works./p -pPackages are grouped by directory under ttlatest/tt or -ttcontrib/tt. The directory name is typically the same as the -package name. For example, the ttboffo/tt package will live in the -ttboffo/tt subdirectory. Exceptions to this rule are historical. -All new packages will follow the rule of package name == directory name. +pPackages are grouped by directory under ttrelease/tt. The directory +name is the same as the package name. For example, the ttboffo/tt package +will live in the ttboffo/tt subdirectory. Exceptions to this rule are +historical. All new packages will follow the rule of package name == +directory name. However, for closely related groups of packages, it is acceptable +to use a heirarchical tree under ttrelease//tt: +prett + release/ + release/boffo/ + release/boffo/lt;boffo filesgt; + release/boffo/boffo-devel/ + release/boffo/boffo-devel/lt;boffo-devel filegt; +/tt/pre pEach directory contains a href=#namingsource and binary tar files/a which have been been compressed using bzip2. The required a -href=#namingformat of these filenames/a is: ttpackage-version[i-src/i].tar.bz2/tt . +href=#namingformat of these filenames/a is: +ttpackage-version-release[i-src/i].tar.bz2/tt . The contents of these files is discussed a href=#package_contents below/a. -150,10 +159,13 pThe version number bmust/b start with a digit and must adhere to the rules in a href=#namingpackage file naming/a above. Higher -version numbers are used for the current version of a package; the -previous stable version (if any) is used for the
RE: strange source packaging?
Much better. There's still a couple of glitches (the whackamole lead-in, and the left side bar comment, but they aren't too critical. Unless we hear complaints in the next day or so, check this in. Rob -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 1:18 PM To: Robert Collins Cc: [EMAIL PROTECTED] Subject: Re: strange source packaging? Robert Collins wrote: All the content changes look great however. If you can clean up the space to tab conversion, I'm happy for this to go in. However as it's a change to the standard... Any objections from any contributor? Okay, I've made the corrections you mentioned. I had smart tabs on earlier. Oops. The newly modified setup is here: http://www.neuro.gatech.edu/users/cwilson/cygu tils/testing/setup.html --Chuck
Re: strange source packaging?
Charles Wilson wrote: Actually, if there's no opposition (hah!) I'll update the documentation to reflect the current situation (e.g. 3 styles) -- but I'd like to mark one of them as the preferred style for new packages. Hopefully mine and robert's style. ;-) Okay, as promised: documentation. If you don't want to unpack the tarball and look at it, go here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/setup.html http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/generic-build-script http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/generic-readme Comments? I hope I covered all the bases, but I may have missed something. I presented two different options for -src packaging... --Chuck src-packages.tar.bz2 Description: Binary data
RE: strange source packaging?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 21, 2002 3:06 PM To: [EMAIL PROTECTED] Subject: Re: strange source packaging? Charles Wilson wrote: Actually, if there's no opposition (hah!) I'll update the documentation to reflect the current situation (e.g. 3 styles) -- but I'd like to mark one of them as the preferred style for new packages. Hopefully mine and robert's style. ;-) Okay, as promised: documentation. If you don't want to unpack the tarball and look at it, go here: Can we get a diff for the HTML page? Rob
RE: strange source packaging?
-Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:13 AM I'll add another penny to make it 2c. I agree with Chris that I'd rather already have the patch applied. Why? If it's for ease of use, then fine - I agree that what the user receives should be patched. However that is somewhat orthogonal to how the download is accomplished. I differences from pristine supplied would be nice but if I really care I would go and find the originals. That's not actually the point. The point is that with some minor setup.exe tweaking, the source download can be done it two parts: 'pristine' + (patch[es] scripts). Then when a local adjustment is made, but the upstream hasn't released a new version, users can get the new source trivially - setup should be smart enough to see the pristine tarball in the /usr/src (or wherever) directory and just download the appropriate patch set. Rob
RE: strange source packaging?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 12:44 AM of the antecedent project. There is no way, given just gcc-2.95.3-5-src.tar.bz2, to revert to the 'original' source -- short of also downloading the 2.95.3 source from www.gcc.org, unpacking both, and doing 'diff -r cygwin-version-of-gcc gnu-version-of-gcc'. And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. Rob
Re: strange source packaging?
Robert Collins wrote: And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. All the GPL requires is that you distribute THE source that YOU used to build THE binary YOU distribute. That's it. --Chuck
RE: strange source packaging?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 10:57 PM To: Robert Collins Cc: Corinna Vinschen Subject: Re: strange source packaging? Robert Collins wrote: And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. Section 2a is pretty clear. Rob
Re: strange source packaging?
Charles Wilson wrote: Robert Collins wrote: And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. All the GPL requires is that you distribute THE source that YOU used to build THE binary YOU distribute. That's it. Section 2.a You must cause the modified files to carry prominent notices stating that you chaned the files and the date of any change. /Section 2.a A differences file alone doesn't accomplish. You must state in the file header (a prominent place of notice) that you changed the file. Now how many of us do that? Instead we use a ChangeLog to note the changes to the files. The GPL itself doesn't give exception for this method. However, since the Copyright holder, Redhat, uses the ChangeLog method for file change notification then it can be argued that the Copyright holder gave the exception to the license so it can continue without change as far as Cygwin is concerned. But the FSF is the copyright holder the most of the other packages we distribute, have the changed files been given appropriate prominent notice? Back to the subject at hand, source packaging and the con to Robert's argument. I can in my wisdom download the individual binary and accompaning source. At that point I should be able to rebuild an exacting duplicate from the source package with supplied scripts found within the source package (autoconfiguration). Therefore having setup.exe perform any patches by downloading only the patch doesn't meet the criteria layed out by the GPL. Nice thought, but not workable within the wording of the GPL. Section 3, para. 5 These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. /Section 3, para 5 Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
RE: strange source packaging?
-Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 12:20 AM Section 2.a You must cause the modified files to carry prominent notices stating that you chaned the files and the date of any change. /Section 2.a A differences file alone doesn't accomplish. You must state in the file header (a prominent place of notice) that you changed the file. Given the definition of a prominent place of notice, it can be argued that a difference file is just that. It's prominent and states the exact changes made - in both human and computer readable form no less. Back to the subject at hand, source packaging and the con to Robert's argument. I can in my wisdom download the individual binary and accompaning source. At that point I should be able to rebuild an exacting duplicate from the source package with supplied scripts found within the source package Exactly. 'source package' here can mean more than one file. There is no requirement in the GPL that the source be provided as a single entity, just that it be provided in it's entirety. So I don't understand your reasoning for why a pristine source + patches + cygwin build script does not meet the criteria. Certianly debian + *BSD ports systems seem to find it feasible. Section 3, para. 5 These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. /Section 3, para 5 Yup. That's what we are conforming with. Rob
Re: strange source packaging?
On Wed, Apr 17, 2002 at 08:21:57PM -0400, Charles Wilson wrote: http://cygwin.com/ml/cygwin-apps/2001-11/msg00510.html Wow. Insightful email. as usual... Well, I guess I haven't been paying much attention to your and Robert's packages. I'd forgotten that I'd suggested that we package as we see fit and foolishly looked to what I supposed was the final word on the subject. It's been a bit of a mess. In my original email to this thread, I summarized the three packaging styles (I won't call them standards) that are currently, actually, in use. That doesn't mean I think having 3 different styles -- only one of which is actually documented somewhere official -- is a good idea. OTOH, since the longwinded discussion last November (and its resolution sans an actual standard), Robert and I (and a few others) have been standardizing one way (which was a compromise in and of itself). So there are only 3 extant styles, not 47. Which is something. If I'm looking over a package for inclusion I'm currently accepting two styles: package-ver-subver/ ... or package-ver-subver.patch package-ver-subver.sh package-ver.tar.[bg]z[2*] -- The pristine source Can we agree to use and document only these styles? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: strange source packaging?
On Thu, Apr 18, 2002 at 10:44:10AM -0400, Charles Wilson wrote: Both style 1 and style 2 in my original email obey this. The difference is that style 2 packages -- gcc, binutils, make, etc -- don't have package-ver-subver/CYGWIN-PATCHES/a-patch in fact, they don't have 'a-patch' at all. They are, in effect, forks of the antecedent project. There is no way, given just gcc-2.95.3-5-src.tar.bz2, to revert to the 'original' source -- short of also downloading the 2.95.3 source from www.gcc.org, unpacking both, and doing 'diff -r cygwin-version-of-gcc gnu-version-of-gcc'. Granted, new packages should never be style 2. But style 2 is in use. I'm talking about style 2. I'm using it for my packages. I don't see a need that the Cygwin package needs the patch from the original version. The pristine source is available elsewhere. We're responsible for the Cygwin version. In the long run the maintainer of a package should try to get his/her changes back into the main trunk anyway (I know, I never did that for inetutils). So the whole point is to get rid of the extra Cygwin patch and to offer the pristine sources anyway since they already contain the Cygwin patches. E.g the openssh sources are the original sources, just repacked to untar into the correct source dir according to our standards. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: strange source packaging?
Corinna Vinschen wrote: I'm talking about style 2. I'm using it for my packages. I don't see a need that the Cygwin package needs the patch from the original version. The pristine source is available elsewhere. We're responsible for the Cygwin version. In the long run the maintainer of a package should try to get his/her changes back into the main trunk anyway (I know, I never did that for inetutils). So the whole point is to get rid of the extra Cygwin patch and to offer the pristine sources anyway since they already contain the Cygwin patches. E.g the openssh sources are the original sources, just repacked to untar into the correct source dir according to our standards. I don't buy that everything should go into the main trunk. Do you really thing that the cygwin-specific readmes should be (or would be) incorporated into the upstream versions of all these project? or the postinstall.sh scripts? Even after all the substantive, code-based changes are accepted by the upstream folks, there are still a number of changes in the average cygwin package that just don't belong in the main trunk. Now, if you're arguing that those non-trunk-worthy changes should just be shipped -- without a reversal patch -- then fine, let's have that discussion. (For my part, it's academic; I prefer the rpm-like ship orig source tarball + patch + script (spec file...) style, anyway.) The argument for style 1 against style 2 is this: Does anybody, other than Chris, have ANY idea what the differences between gnu-gcc-2.95.3 and cygwin-gcc-2.95.3-5 are? How many files are changed, and how significantly? What options were used to build the cygwin binary package? Before Chris reluctantly picked up the duty, did anyone other than Mumit have a clue about the minutia of those differences (worse yet, Mumit's version was a fork of the cgywin version, which itself was a fork of the egcs version, which was a fork of the official gnu version...) Granted, gcc is pretty much the 'worst possible case' example, but the end result was that after Mumit dropped out of sight, it was over a year before we had another gcc update. (It was 18 months before some of the dll-building capabilities in binutils that Mumit had working in HIS version, were finally recreated/restored and pushed upstream into the main binutils trunk). Forcing maintainers to generate and include an actual diff in each -src tarball for each new release serves as a kind of reminder: here's how much stuff still needs to be pushed upstream. Heck, I evaluate my success with each release based on how much smaller that diff is...see ncftp... Sure, this kind of thing is the maintainer's purview; perhaps it's too authoritarian to micromanage and say you must do it this way -- OTOH, the size of these patches also serve to advertise to the community how well cygwin support is getting mainstreamed. BUT...having said all of that, I reiterate: I prefer the style 3 over EITHER style 1 or style 2 -- and the question here seems to be document styles 1,2,3, or document 1,(!2),3 or (!1),2,3 So I win, regardless. I really don't have a horse in the 1,2 vs. 1,(!2) vs. (!1),2 race. So, I've made my argument for 1,(!2) but won't defend it; I'll wait for a consensus to emerge and will document the result. --Chuck P.S. geez, I really didn't mean to restart that old November thread...
Re: strange source packaging?
On Thu, Apr 18, 2002 at 11:44:26AM -0400, Charles Wilson wrote: BUT...having said all of that, I reiterate: I prefer the style 3 over EITHER style 1 or style 2 -- and the question here seems to be document styles 1,2,3, or document 1,(!2),3 or (!1),2,3 So I win, regardless. I really don't have a horse in the 1,2 vs. 1,(!2) vs. (!1),2 race. So, I've made my argument for 1,(!2) but won't defend it; I'll wait for a consensus to emerge and will document the result. What about 1 and 2 being actually the same? Except for it would be nice to add a patch file? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: strange source packaging?
On Thu, Apr 18, 2002 at 11:44:26AM -0400, Charles Wilson wrote: The argument for style 1 against style 2 is this: Does anybody, other than Chris, have ANY idea what the differences between gnu-gcc-2.95.3 and cygwin-gcc-2.95.3-5 are? How many files are changed, and how significantly? What options were used to build the cygwin binary package? Before Chris reluctantly picked up the duty, did anyone other than Mumit have a clue about the minutia of those differences (worse yet, Mumit's version was a fork of the cgywin version, which itself was a fork of the egcs version, which was a fork of the official gnu version...) I know this is mainly a rhetorical question but actually, *I* don't have any idea what all of the differences are. I took over some patches from Mumit that are for all intensive porpoises just black magic. However, I have no problems generating the patch files, when required by downloading the tar ball from gcc.gnu.org and then doing the diffs. I have been trying to up-port my changes to the main trunk when possible but I suspect that there are still a few tweaks in the cygwin release that are not in gcc 3.1. From my point of view, when I download the source rpm for a package, I always find it rather annoying that I have to apply patches by hand. I'd rather just have the latest, greatest version of things extracted into a directory where I can type configure/make without any extra thinking involved. My 1c. Now back to this resurrected discusion... cgf
Re: strange source packaging?
Currently, there are three dominant -src packaging standards. 1. As detailed on http://cygwin.com/setup.html#package_contents foo-VER-REL-src.tar.bz2 unpacks thus: foo-VER[-REL]/ foo-VER[-REL]/source files foo-VER[-REL]/subdirs foo-VER[-REL]/subdirs/source files foo-VER[-REL]/CYGWIN-PATCHES foo-VER[-REL]/CYGWIN-PATCHES/the-patch (*) (*) already applied to the source tree. Use this to REVERT to the pristine source. 2. packages which have cygwin-adapted source maintained in a cygwin-hosted CVS repository (e.g. gcc, cygwin itself, binutils, make, a few others). foo-VER-REL-src.tar.bz2 unpacks thus: foo[-VER[-REL]]/ foo[-VER[-REL]]/source files foo[-VER[-REL]]/subdirs foo[-VER[-REL]]/subdirs/source files In this scheme, there is no cygwin patch -- the cygwin version is basically a fork. If you want to know how the cygwin-specific source differs from the official version, you must get both sources and do the diff yourself. 3. A method hashed out on the cygwin-apps list last november: patches to vendor source trees - discussion: http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00046.html -src package standard: proposal #5 and #5a: http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00490.html foo-VER-REL-src.tar.bz2 unpacks thus: foo-VER.tar.[bz2|gz] -- original source code foo-VER-REL.patch-- the cygwinization patch foo-VER-REL.sh -- a script to drive the whole unpack/patch/configure/build/re-package procedure. As to why the .gz(or.bz2) compressed original source code tarball is included inside an .bz2 -src package, when the internal tarball can't really be compressed further: it's the original. If I ungzip it, and then bzip it, then it isn't the original version EXACTLY as distributed by the upstream folks... Hope that helps explain it. --Chuck Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? This is pretty peculiar and mroeover defeats any additional compression .bz2 could have versus .gz (compressed data is uncompressable even if it could be comperssed better with another compressor ^_^)? Just for curiosity =) BTW: in creating UPX package it'll have the strange erquirement that UPX source package needs also UCL source package (the installed binary isn't enough). Can that precedence be used, maybe documenting it in the Cygwin-doc/upx-...-1.txt o I shoul better include the sources needed to compile it also in UPC src directory to need only UCL library installed only? -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: strange source packaging?
As to why the .gz(or.bz2) compressed original source code tarball is included inside an .bz2 -src package, when the internal tarball can't really be compressed further: it's the original. If I ungzip it, and then bzip it, then it isn't the original version EXACTLY as distributed by the upstream folks... Hope that helps explain it. Thanks for the long explanation (it seems that there is always some part of this ML that doesn't hit my eyes, even if I read it all ^_^)... anyway the base is exact original is preferred upon size if I got it right.. right? (even if a gunzip source | bzip2 dest would alter in no way the tar and I see no diffrence between 'dest' and 'source' in any pratical way (uhm.. people )... but inter-programmer politics is not my concern, your answer fully satisfied my curiosity) Thanks, Lapo PS: I can see at least a motivation for using exact original package now: so that people can use md5sum and get convinced that the included file is really exactly the original... -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: strange source packaging?
Lapo Luchini wrote: PS: I can see at least a motivation for using exact original package now: so that people can use md5sum and get convinced that the included file is really exactly the original... Bingo. --Chuck
Re: strange source packaging?
On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? cgf
Re: strange source packaging?
Christopher Faylor wrote: On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? ??? Chris, are you disagreeing with this post http://cygwin.com/ml/cygwin-apps/2002-04/msg00298.html, or repudiating the packaging method used by the packages listed below (and maybe others I missed), or merely asserting that when gzip -dc foo.tar.gz | bzip2 foo.tar.bz2, then foo.tar.bz2 is still just as original as foo.tar.gz? --Chuck autoconf-devel autoconf-stable autoconf automake-devel automake-stable automake bzip2 cygutils gdbm gettext jbigkit jpeg libbz2_0 libintl libintl1 libncurses5 libncurses6 libpng libpng2 libreadline4 libreadline5 libtool-devel libtool-stable libtool libxml2 libxslt mktemp ncftp ncurses pkgconfig popt readline terminfo tiff units wget which xpm-nox zlib
Re: strange source packaging?
On Wed, Apr 17, 2002 at 03:12:00PM -0400, Charles Wilson wrote: Christopher Faylor wrote: On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? ??? Chris, are you disagreeing with this post http://cygwin.com/ml/cygwin-apps/2002-04/msg00298.html, or repudiating I'm referring to this passage in http://cygwin.com/setup.html: * Source packages are extracted in /usr/src. On extraction, the tar file should put the sources in a directory with the same name as the package tar ball minus the -src.tar.bz2 part: boffo-1.0-1/Makefile.in boffo-1.0-1/README boffo-1.0-1/configure boffo-1.0-1/configure.in etc... That is not the case for wget. cgf
Re: strange source packaging?
On Wed, Apr 17, 2002 at 04:31:04PM -0400, Charles Wilson wrote: As I recall, the your final word on the matter -- before the thread degenerated into yet another We need an 'install all' option in setup discussion -- was (more or less) whatever. All these proposals sound fine. As long as it makes sense to the maintainer himself: http://cygwin.com/ml/cygwin-apps/2001-11/msg00510.html Wow. Insightful email. Since last November, ALL of my packages, and most of Robert's and a few others, have been like this: foo-VER-REL-src.tar.bz2 contains foo-VER.tar.[gz|bz2] -- whatever the upstream folks distribute foo-VER-REL.patch foo-VER-REL.sh and that's it. I'm even a mildly annoyed when Corinna insists that (oldstyle) -src packages MUST unpack into foo-VER-REL/ instead of foo-VER/ since MY packages -- as agreed last November -- contain the pristine upstream sources. And the upstream maintainers know *nothing* about our release numbers. Well, I guess I haven't been paying much attention to your and Robert's packages. I'd forgotten that I'd suggested that we package as we see fit and foolishly looked to what I supposed was the final word on the subject. I'll just leave the documentation as is so we can have this truly delightful conversation again in a couple of months. If gzip -dc foo.tar.gz | bzip2 foo.tar.bz2 is a marginal is it 'pristine' or not case, then tar xvzf foo-VER.tar.gz mv foo-VER foo-VER-REL tar cvjf foo-VER???.tar.bz2(*) foo-VER-REL/ tar cvjf foo-VER-REL-src.tar.bz2 foo-VER???.tar.bz2 foo-VER-REL.patch foo-VER-REL.sh (*)foo-VER???.tar.bz2 is definitely NOT the pristine source. Its internal dirname has changed, as well as the tarball name, and compression type. And what the hell do I call it? I can't name it 'foo-VER-REL.tar.bz2' because that's the name of the binary package. I can't call it 'foo-VER.tar.bz2' because then I'll have multiple versions: the 'original' upstream one -- unpacks into foo-VER/ two or three somewhat modified ones, depending on how many releases I create: -1's foo-VER.tar.bz2 unpacks into foo-VER-1/, -2's foo-VER.tar.bz2 unpacks into foo-VER-2, etc. But, each contains exactly the same code. I can't call it 'foo-VER-REL-src.tar.bz2' because that's the name of my larger -src tarball, which contains the pristine(hah!) tarball + .patch and .sh. So I leave it foo-VER.tar.[bz2|gz], leave it so that it unpacks into foo-VER, just like the upstream folks made it in the first place. Yeah, yeah. I don't need another 183 line justification message, thanks. I've got it. The wget packaging is just peachy. cgf
Re: strange source packaging?
http://cygwin.com/ml/cygwin-apps/2001-11/msg00510.html Wow. Insightful email. as usual... Well, I guess I haven't been paying much attention to your and Robert's packages. I'd forgotten that I'd suggested that we package as we see fit and foolishly looked to what I supposed was the final word on the subject. It's been a bit of a mess. In my original email to this thread, I summarized the three packaging styles (I won't call them standards) that are currently, actually, in use. That doesn't mean I think having 3 different styles -- only one of which is actually documented somewhere official -- is a good idea. OTOH, since the longwinded discussion last November (and its resolution sans an actual standard), Robert and I (and a few others) have been standardizing one way (which was a compromise in and of itself). So there are only 3 extant styles, not 47. Which is something. I'll just leave the documentation as is so we can have this truly delightful conversation again in a couple of months. Actually, if there's no opposition (hah!) I'll update the documentation to reflect the current situation (e.g. 3 styles) -- but I'd like to mark one of them as the preferred style for new packages. Hopefully mine and robert's style. ;-) Yeah, yeah. I don't need another 183 line justification message, thanks. I've got it. Chris, in private mail I would've just sent you the one link and I *know* that would've been sufficient. However, on a public list a little more info, background, and justification is needed -- if only to forestall the inevitable hue and cry. The wget packaging is just peachy. g --Chuck
