gettext 0.16.1

[Charles Wilson]

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).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-cygport-0.3.8-1.tar.bz2
Type: application/octet-stream
Size: 3843 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20080215/a3e55739/attachment.obj>
-------------- next part --------------
--
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/