This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: patches to vendor source trees - discussion
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