This is the mail archive of the
mailing list for the Cygwin project.
Re: patches to vendor source trees - discussion
Robert Collins wrote:
> 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.
>>My proposal (revised)
>> Use the standard RPM tree (SOURCES, BUILD, SPEC, RPMS, SRPMS)
>> -src is a tarball which contains
>> SOURCES/foo-VER-REL.diff (creates the cgywin README)
>> SOURCES/foo-VER-REL-X.diff (if necessary)
>> .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
> deep might be
> and wide is what I've been talking about.
> What you've ben talking about AFAICT is wide+deep.
> are wide,
> and then undersources, you go deep.
Yeah, for my initial version, you are correct. I had %SOURCES/foo/,
%DOCS/foo/, %INST/foo/, etc. Now I've scrapped all that. Just %SOURCES.
>>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
> 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
> 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
Well, I guess I can live with it. The only remaining problem is one I
haven't yet mentioned. I was hoping it wouldn't come up. Binary data (and
related: multiple source archives)
For instance, the libtiff -src package contains
as well as the expected
There's no way that (d) -- or any other .patch -- can be used to create (a)
or (b). Now, those files don't HAVE to be distributed as .tar.gz's -- they
could just be unpacked (by me as the maintainer) under CYGWIN-PATCHES, and
then the .patch file could create those *unpackaged* files directly. So
*perhaps* that's a non-issue.
The other problem that may crop up, but hasn't yet: *TRUE* binary data.
for instance (using libtiff again), in order to get 'make test' to work, my
README says "go download ftp://ftp.onshore.com/pub/libtiff/v3.4pics.tar.gz"
and unpack it within your src directory." Note that it contains a bunch of
.tiff files -- binary data. Note also that it's no longer available from
ftp.onshore.com, you now have to go to ftp.remotesensing.org, but using
ACTIVE mode ftp only...quite a barrier. Files moving around on the web,
restrictions on download protocols so that you can't be behind a firewall.
Sure would be nice if we just included this in our -src tarball...
What if I had wanted to include that within the original source archive? I
can't include it as a .tar.gz file --- but since it *contains* binary data,
I (as the maintainer) can't unpack it within MY src dir and THEN generate
the patch. Patch will barf.
What this really requires -- if we want to allow it -- is to have *TWO*
primary source archives within the main -src one;
(this is the official tiff archvie from www.libtiff.org)
(also a primary archive)
and then the .spec (.sh, .rule) file can handle the appropriate unpacking
(note that the official libtiff tarball doesn't follow our naming scheme --
e.g. the version number begins with 'v'. Also, the secondary source
tarball doesn't have a name that is obviously related to tiff. That's the
reason I pushed for subdirs under SOURCES -- to categorize things that
aren't obviously related but should be. OTOH, *if* setup gains the ability
-- later -- to record the few files that are actually unpacked from the
cygwinish -src tarball, then they can be easily uninstalled without needing
a special SOURCES/tiff/ subdir.)
These are some of the reasons why, for all of its obvious failings, I
believe the rpm format has many advantages over other autobuild systems.
It may be ugly, but it sure is flexible. 'Course, I'm beating a deceased
equine since Cygnus == Red Hat...