This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygport-0.9.3 in release-2
Yaakov (Cygwin Ports) wrote:
>> They were called "rollup" patches. T.E.D. releases patches roughly every
>> week, and then every month (or two, or three), he combines all patches
>> dating back to an official release into a "rollup" patch -- and these
>> "rollup" patches are in the shar-archive-auto-apply format. You can see
>> an example in the current cygwin ncurses-5.5 package (yes, two years
>> old. I know...) T.E.D. also provides the patches to update a 5.x tree
>> to 5.x+1 in that form:
>
>> ftp://invisible-island.net/ncurses/patches/
>
> Looking at 5.5-3, all those patches can be in PATCH_URI instead.
Even the "rollup" patch?
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060909-patch.sh.bz2
>> That leaves only:
>> cvs topdir support
>> postinst hook support
>
> cvs topdir: this has little benefit and would break ABI.
It only breaks the ABI (B?) if you do it the way you suggested:
http://cygwin.com/ml/cygwin/2008-05/msg00038.html
> I suppose a cleaner solution would have been to add a '-d
> ${CVS_MODULE##*/}' to the checkout command, but doing that now would
> break existing -src packages.
Anyway, that wouldn't actually work either. Modules aren't necessarily
directory names. For instance, take the binutils module:
binutils -a naked-binutils naked-opcodes naked-bfd naked-libiberty \
naked-include naked-gas naked-gprof naked-ld naked-gold \
naked-elfcpp naked-intl src-support naked-texinfo naked-cpu
If I wanted to checkout the 'naked-binutils' module, in /THAT/ case I
would really expect to get
src/binutils/<STUFF>
and would be annoyed to get
naked-binutils/<STUFF>
There's really no "rule" like '-d ${CVS_MODULE##*/}' that is universally
applicable: the module name and the -d option (if present) are
orthogonal controls. You don't want to tie them together.
The way my patch does it, there is no API breakage -- but you have a new
API entry point [the new CVS_DIR variable]. The price of API
preservation is a proliferation of new ones; just ask Bill Gates.
The benefit of allowing some mechanism to pass a -d option to the cvs
checkout is that I can ensure that my cvs.cygclass-generated origsrc
tarball has the same directory layout as a make-dist-generated one.
But whatever. I'll live with it. Worst case, I'll manually repack the
tarball and comment-out the inherit cvs.cygclass. Besides, the only
package I know of that has this issue is libgeotiff -- which moved to
subversion a few months ago, anyway.
So, it's probably moot for all current packages.
> postinst hook: RESTRICT="postinst-doc" was supposed to be a workaround.
> How was this not sufficient?
It is sufficient to override the default behavior of the post-install
phase with respect to documentation; that's what the urxvt packages care
about. But other packages (unknown at this time, but I'm not possessed
of sufficient hubris to rule them out) might need to override/customize
some other phase:
__src_postinst() {
__prep_symlinks;
__prepdoc;
__prepetc;
__prepman;
__prepinfo;
__prep_empty_dirs;
__prepstrip;
__prep_libtool_modules;
}
But I guess you can continue adding new RESTRICT options on an ad-hoc
basis. A draw-back to that method is all I can do is STOP the automated
system from doing something at the end of the install-phase. The only
chance I have to actually DO anything during the install phase is in
src_install, which precedes all that.
Hopefully there are no, and never will be any, ordering dependencies
between the post-install phases; For example: suppose, for some reason,
that cygport develops an assumption that __prepinfo MUST always come
after __prepman. If I want to do something funky with the info files,
all I can do is RESTRICT_postinst-info -- and do my funky thing MUCH
earlier, in src_install.
So, now, MY "prepinfo" happens before __prepman.
But, I suppose there's no sense borrowing trouble; "Sufficient unto the
day is the evil thereof".
--
Chuck