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


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



Attachment: 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/

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