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
