Larry Hall (Cygwin) wrote:
Looks like for now you need to build your own 0.16.1 if you need it and can't wait for the maintainer to update it.
The maintainer of gettext would be a lot more willing to update gettext if he wasn't still -- after 1 year, 3 months, and 23 days -- futilely trying to get just the *preliminary* set of required patches accepted into the cygport packaging tool. [*]
Then, the gettext maintainer could see about updating the now sadly bit-rotted cygport patch for "relocatable" packages -- like gettext and libiconv.
THEN, maybe the gettext maintainer would look into updating gettext.But right now, the gettext maintainer is pretty d*** pissed off that he ever adopted the cygport tool in the first place. The gettext maintainer, in fits of momentary insanity, sometimes considers /officially/ forking cygport -- as opposed to the unofficial fork sitting on his hard drive for the last year+. Because that'd be a lot easier -- and a lot less demeaning -- than begging for crumbs for months and months and months. But then he realizes he's doing a poor-to-awful job of maintaining the packages he has NOW, and has no business taking on any more.
But then, the gettext maintainer is used to open-source development where project leads actually like receiving honest-to-god patches instead of the normal litany of PIBKAC bug reports and gimmee-gimmee feature demands. The cygport development "process" is...different than that.
Here endeth the rant -- which I realize is not likely to win friends or influence people -- especially the cygport maintainer. But sometimes you just gotta vent. I'm a fairly patient guy, but even I have my limit; after more than a year, I'm getting close to mine.
-- Chuck[*] To be sure, a few of my patches -- or usually, just *parts* of a few of them -- have been incorporated. But it's very very very very very very very very slow going. Plus, patches are never accepted as they are; they are invariably re-coded completely according to some hidden higher design -- which means I have to re-code the ignored bits following these "hints" after every new release: the contents of these directories are all substantially different:
old-patch-cygport-0.2.5/ old-patch-cygport-0.2.6/ patch-cygport-0.2.7/ patch-cygport-0.2.9/ patch-cygport-0.3.1/ patch-cygport-0.3.1-2/ patch-cygport-0.3.1-3/ patch-cygport-0.3.6-1/ patch-cygport-0.3.8-1/ relocatable/So the burden of maintaining out-of-tree patches is even higher than normal. If I hadn't spend so much effort converting all my packages from g-b-s to cygport -- and developing my patches as a necessary adjunct of that effort -- back in the fall of '06...
Most recent patchset (as of CVS cygport 0.3.8, Jan 4 2008), not including the (bit-rotted) relocatable stuff:
cygport-mixedmode-and-cvs-topdir.patch:
bin/cygport.in (__src_fetch): add comment
lib/cvs.cygclass (cvs_fetch): allow cygports to specify
a "-d ${CVS_DIR}" argument by defining the CVS_DIR variable.
Otherwise, the module directory name is used, as previously.
This is useful if the desired source code is not a top-level
module in the cvs repository (e.g. libgeotiff).
cygport-multiple-postinstall.patch
bin/cygport.in (__prepetc): rework so that each (sub)package
in a cygport can have its own postinstall or preremove script.
${C}/${PN}.sh, ${C}/postinstall.sh, ${C}/${PN}.postinstall
are all associated with the "main" package ${pkg_name[0]},
but if more than one of these three exist, an error is
triggered. ${C}/preremove.sh and ${C}/${PN}.preremove
are both associated with the "main" package ${pkg_name[0]},
but if both exist an error is triggered. Otherwise, each
of ${C}/${pkg_name[1..N]}.postinstall and
${C}/${pkg_name[1..N]}.preremove are associated with the
specified package ${pkg_name[1..N]}, if the file(s) exist.
cygport-hooks.patch: adds support for
src_unpack_post_hook
src_prepinstalldirs_hook
src_postinst_hook
bin/cygport.in (__src_prep): after all other preparation,
call unstable function src_unpack_post_hook if it is
defined. This can be useful in the following cases:
(1) to change the permissions on files created by unpacking
tarfiles or applying patches earlier in __src_prep
(specifically, adding +x execute permissions)
(2) Other re-organizations of files extracted from tarballs
or generated by applying patches. See the gdbm and tiff
cygports for examples.
(__src_prepinstalldirs_hook_exec): call unstable function
src_prepinstalldirs_hook if it is defined. No examples of
current use, but included for symmetry.
(__src_postinst_hook_exec): call unstable function
src_postinst_hook if it is defined. This can be useful if,
for instance, the default docdir usr/share/doc/${PN}-${PV}
is not appropriate, and should be "corrected" prior to
packaging. See the rxvt-unicode-X cygport for an example.
(main command parsing case statement) [postinst*]: call
__src_postinst_hook_exec after __src_postinst.
(main command parsing case statement) [inst*]: call
__src_prepinstalldirs_hook_exec before __prepinstalldirs,
and __src_postinst_hook_exec after __src_postinst.
(main command parsing case statement) [almostall, all]:
ditto, as part of __stage Installing.
cygport-custom-cmds.patch
custom-show display a list of all functions callable via customN-*
customN-* where * is the name of an function declared by cygport,
and N is a digit, 0..9, that indicates the number
of additional arguments to remove from the command line,
and pass to the target function as its arguments. That is,
custom0-__show_help
will call __show_help() with no arguments, while
custom1-error "an error message"
will call error() with "an error message" as its argument.
Try experimenting with:
customN-custom_dummy <arg1> <arg2> ... <argN>
Used in conjunction with the (separable) testsuites in the cvs
cygport.
cygport.in (custom_dummy): public N-ary function that prints
all N arguments to stdout. Used for demonstration purposes.
(__custom_dummy_core): private support function for
custom_dummy. N-ary function that simply prints all N
arguments to stdout.
(__show_help): add documentation for custom-show and customN-*
commands.
(main command parsing case statement) [custom-show]: add new
command. Shows all public functions available in the current
cygport that can be called using the customN-* command.
(main command parsing case statement) [customN-*]: add new
command(s).
patch-cygport-0.3.8-1.tar.bz2
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
