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 Message-ID: <3BE702C3.5010008@ece.gatech.edu> Date: Mon, 05 Nov 2001 16:21:07 -0500 From: Charles Wilson 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 CC: Corinna Vinschen Subject: Re: patches to vendor source trees - discussion References: <3BE4D4A7 DOT 2070900 AT ece DOT gatech DOT edu> <20011104104732 DOT X17306 AT cygbert DOT vinschen DOT de> <1004867892 DOT 5388 DOT 54 DOT camel AT lifelesswks> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > On Sun, 2001-11-04 at 20:47, Corinna Vinschen wrote: >>I would prefer to keep it simple. And since we already have seen >>implementations of rpm for Cygwin (regardless of the "replace >>DLL/EXE while running" problem) I would propose the rpm way which >>would easily fit in our current packaging scheme. >> >> > > I've been trying to keep well away from the rpm vs deb issue. I've not > been suggesting that setup be altered *at all*. I don't think setup need be altered. I think Corinna's suggesting that we adopt the rpm directory tree for the internal layout of our -src tarballs. > And yes, I think that cygwin's setup.exe should be quite limited in > scope for installation of source. Sounds like Corinna's advocating what is essentially a compromise between Robert's proposal and mine: 1) use a multiple directory heirarchy. Not as many as I wanted, but sticks with the RPM standard set. %/BUILD %/RPMS %/SOURCES %/SPECS %/SRPMS. where % = /usr/src/cygwin/ 2) single patch file (for new style -src dists) except that there are a few twists that don't originate from either Robert or my proposal: I assume that, in Corinna's scheme, RPMS and SRPMS will NOT, at present, contain *actual* rpms nor srpms. Mebbe we can use those dirs -- on an interim basis -- as the place where newly built .tar.bz2's and -src.tar.bz2's are stored. But primarily they're just placeholders right now. Corinna is not suggesting any change to the internal format of the -src tarball. It's just a tarball, unpacks into foo-ver-rel/*. Period. Except that setup no longer unpacks it. If the package maintainer desires, he may also choose (for new versions/new packages) to : a) take the pristine tarball and rename it according to current conventions (*) b) place a similarly named .diff file *on the cygwin mirror* c) place a similarly named .spec file *on the cygiwn mirror* If these extra files exist, setup will download them into %/SPECS and %/SOURCES. This may require changes to cgf's upset script, additions to the setup.hint and setup.ini grammar, as well as mods to setup.exe itself. It is unclear whether the .spec file must be a true rpm-style spec file, or just a file that ends in .spec (might be a debian-like rules file? or a cwilson-like build script?) (*) since there is no distinction now between an "old-style" -src tarball and a 'renamed but really just the pristine, unpatched src' tarball, she asserts that -src tarballs will now just be copied into %/SOURCES and NOT unpacked. IF there is a .diff file, then the user must apply it manually. If the is NO .diff file then assume old rules: unpacked tarball will be pre-patched. -------------------- I don't like this, for several reasons: (1) requires too much mucking around with setup, upset, setup.ini, and setup.hint. (2) One of the BIG advantages of rpm/deb is EVERYTHING goes in one archive. -src.deb or .srpm. Stuff won't get lost, or accidentally desynchronized. (3) I think BOTH my proposal and Robert's proposal are simpler, from the tools side. Neither really seems to require ANY changes to setup.ini, upset, setup.hint. Robert's does seem to require changes to setup.exe. Mine: pkg maintainers, make your -src package look like this: (the -src.tar.bz2 will contain a pristine source tarball itself, which is merely placed in %/SRC/ (because of the paths in the downloaded -src.tar.bz2 file). The secondary internal pristine tarball is NOT further unpacked) setup.exe, download the -src archive and unpack into /usr/src/cygwin/ Robert's: pkg maintainers, make your -src package look like this: (the -src.tar.bz2 will contain a pristine source tarball itself, which is placed in % and IS further unpacked) setup.exe, download the -src archive and unpack into % (usr/src ?) That will create %/fooVER.tar.bz2 and %/fooVER.dif Unpack that secondary tarball, and then apply the fooVER.dif patch. This will create a %/fooVER/debian directory with a rules file, etc My proposal (revised) Use the standard RPM tree (SOURCES, BUILD, SPEC, RPMS, SRPMS) -src is a tarball which contains SOURCES/foo-VER-REL-orig.tar.bz2 SOURCES/foo-VER-REL.diff (creates the cgywin README) SOURCES/foo-VER-REL-X.diff (if necessary) SPECS/foo-VER-REL.* .spec or .sh or .rule or whatever. setup unpacks this into /usr/src/cygwin. the end. Nothing else is specified yet. How can this work with Robert's proposal? The following is optional: in setup.exe: if SPECS/foo-VER-REL.rule exists in the tarball (not .sh nor .spec), then go ahead an also unpack foo-VER-REL-orig.tar.bz2. Also, go ahead and apply the foo-VER-REL.diff patch (which should create his debian/ directory filled with the "real" debian-like rule file, etc) In other words, if -src.tar.bz2 contains SPEC/*.rule, then follow the debian rules; ONE diff file which creates the debian-style rules file and whatnot. Robert's '%' == /usr/src/cgywin/SOURCES. Yeah, it's complicated, but no more so than the current system of ' download, unpack, and then try to follow the (nonexistant?) build instructions in /usr/doc/Cygwin/foo.README. --Chuck