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


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