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]
Other format: [Raw text]

Re: patches to vendor source trees - discussion


Okay, after two days we've gotten one reply, from Kevin Roth (a 
nonmaintainer, I think).  But nothing else.

Are any *current* maintainers going to help us decide here, or am I going 
to have to fly down under for a Robert-v-Chuck arm-wrestle match to settle 
this?

See http://www.neuro.gatech.edu/users/cwilson/cygutils/packaging/

To restate the positions;
  mine: (#1)
    -src tarball contains
       cygwin/SOURCES/<pristine tarball, without renaming or repacking>
       cygwin/SOURCES/<patchfile>
       (possibly other stuff in cygwin/SOURCES/, if necessary)
       cygwin/SPECS/<build script or makefile>
    newly generated tarballs placed in cygwin/RPMS
    newly generated src tarballs placed in cygwin/SRPMS
    since setup will unpack the cygwin-distributed -src tarball under 
/usr/src, all this stuff therefore happens in /usr/source/cygwin/*/
    the build script, when run, unpacks the pristine tarball and renames 
the unpacked directory to be "pkg-ver-rel" instead of whatever the upstream 
developers may have chosen for their source packages (mv tiff-v3.5.5/ 
tiff-3.5.5-2/).  This way, we fit into "the cygwin way" but don't have to 
repack the "pristine" tarballs at all.
   (Alternatively, we don't *HAVE* to do this.  We can just use whatever 
dirname the upstream folks put in their pristine tarball.  It's all 
controlled by the script in SPECS/)

Good points:  more "RPM" like.  Also, the build script is right there -- no 
need to unpack & patch first; the build script will do that for you. 
Therefore, this is more automated.

Bad points: assumes a cygwin/*/ structure.  (Not *necessarily* 
/usr/src/cygwin/*/ -- it could be ~/cygwin/*/)

---------------------------------------------------
   Robert's: (#3)
     -src tarball contains
        <pristine tarball, without renaming or repacking>
        <patch>
      since setup unpacks these under /usr/src, these files end up right 
there in /usr/src.
      newly generated tarballs are placed *right here* (in /usr/src)
      ditto newly generated -src tarballs
      Currently, one must manually unpack the pristine tarball, and apply 
the patch.  (Later, perhaps setup can do this for us).  Then, the build 
script is created inside the unpacked source directory.

Good points:  self contained. The build script need not assume anything 
about the "surrounding' directory structure.  once the user unpacks and 
patches, <srctop>/CYGWIN-PATCHES/buildscript will do all the work, and 
generates the new tarballs in <srctop>/..

Bad points: User must manually unpack and patch (or setup must do it). 
IMO, having the build script inside the source tree is awkward.  Also, 
there seems to be little provision for additional patches or archives if 
the "pristine" src archive + 1patch isn't enough to properly handle the 
port (cf. /usr/doc/Cygwin/ncurses-5.2.README)

---------------------------------------------------
   Worst of both worlds: (#2)
     -src tarball contains
       cygwin/SOURCES/<pristine tarball, repacked, renamed>
         renamed so that the tarball follows some agreed-upon
           standard name (foo-ver-origsrc.tar.bz2 ?)
         repacked so that it will unpack into an agreed-upon
           standard directory (foo-ver-rel/ ?  foo-ver/ ?)
           instead of whatever random thing the upstream folks
           picked (jpeg6b?  tiff-v3.5.5? Ugh).
     apply the patch, and then the build script is created within
the unpacked source directory.  It is assumed that the user (or setup) will 
unpack the pristine source into cygwin/BUILD.  That script will 
(eventually) generate the new tarball in cygwin/RPMS, and the new -src 
tarball in cygwin/SRPMS.

good points: Closer to the RPMish structure. (?)

Bad points: repacking, renaming the "pristine" tarball.  Also, assumes a 
lot about *where* the end user will manually unpack -- unless setup does 
this for us. Also the single src archive + 1 patch only problem.

---------------------------------------------------

--Chuck


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