This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Oh, okay.

>>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.
> 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. 
%SPECS. 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.
> 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
> 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.

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
(a)  CYGWIN-PATCHES/libtiff-lzw-compression-kit.tar.gz
(b)  CYGWIN-PATCHES/tif_rpt_3.4b33.tar.gz
   as well as the expected
(d)  CYGWIN-PATCHES/tiff-3.5.6beta-2.patch

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"; 
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, you now have to go to, 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
     (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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]