This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: patches to vendor source trees - discussion
On Tue, 2001-11-06 at 08:21, Charles Wilson wrote:
> Robert Collins wrote:
>
> > 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.
I must have misread Corinna's mail - oops.
>
> > 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.
..or maybe I didn't misread. This sounds like a setup.exe change to me
:}.
For the record, apt doesn't unpack it either (be default). I wasn't
suggesting we change this though.
> 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.
Yup.
> 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?)
...
> --------------------
>
> I don't like this, for several reasons:
>
> (1) requires too much mucking around with setup, upset, setup.ini, and
> setup.hint.
Yes.
> (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/
k. thats easy.
> 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)
This could be just like yours IMO. I'd prefer that really. (-src.tar.bz2
contains a inner tarball that is *not* unpacked + the global patch.
> 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.
I still don't like %SOURCES + %SPECS. IMO it's _not_ a deep vs wide
thing.
deep might be
%foo/SPECS
%foo/DOCS
%foo/SOURCES
and wide is what I've been talking about.
What you've ben talking about AFAICT is wide+deep.
%SOURCES
%SPECS
%DOCS
are wide,
and then undersources, you go deep.
> 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.
I think that there is more being read into what I've suggested than I
intended.
let me rephrase. (incorporating your idea of wrapped source tarballs).
setup.exe code changes. NONE.
maintainer patch management and build process changes. NONE.
-src tarball creation changes:
1) the uploaded tarball changes. It becomes a tarball with two files in
it.
a) pristine vendor source.
b) a single patch - that makes the pristine source look like *THE
CURRENT SRC TARBALL LOOKS LIKE*
So Chuck, I still dont' see - HOW this conflicts with your multiple
patch approach. The user sees the same thing once they patch the source
dir.
Rob