Mail Archives: cygwin-apps/2001/11/16/23:59:36
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
- Raw text -