This is the mail archive of the cygwin-apps@cygwin.com 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:

> 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


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