This is the mail archive of the
mailing list for the Cygwin project.
Re: generic-build-script extension to update version numbers in README
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
- Date: Fri, 18 Nov 2005 19:47:02 -0500
- Subject: Re: generic-build-script extension to update version numbers in README
- References: <437E4CD3.firstname.lastname@example.org>
Christian Franke wrote:
the build-script of the smartmontools package creates the
"Cygwin/package-*.README" file from
"srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the
current version/release numbers.
This might be useful for other packages to avoid extra editing of README
on each minor release.
Christian, please don't take offense; the following semi-rant is not
aimed at you, but is a product of my frustration with gbs. It's become
an issue for me in that the difficulty of trying to track changes in the
gbs is a significant portion of my effort when releasing a new version
of an existing package.
I'd like to make a request: gbs is getting out of control with this
feature and that feature added. Some of these tasks are NEVER going to
be performed by anyone other than the primary maintainer: has anyone
actually used 'foo.sh list' or 'foo.sh depends'?
It's a nice feature, but how useful is it, really? Ditto this
maintainer-only 'muck with the README' script. Could these added
features be simply refactored into ancillary scripts instead of
integrated into the main gbs? E.g.
./foo.sh externaltool /path/to/update-readme
where the gbs's externaltool function would simply source the
update-readme fragment -- and the update-readme fragment would inherit
all of the variable settings from the top of the gbs. I'd figure that
'update-readme' would NOT be shipped with cygwin packages, but could be
downloaded from the sourceware cvs by a maintainer who wanted to use it
on her machine when maintaining her package foo. Thus, I don't see
exploding out a bunch of 'build.frag' and 'prep.frag' and 'mkpatch.frag'
fragments; the current intrinsic functions in the gbs should stay there.
The reason I bring this up is that recently I re-packaged cvs (and am
also working on updating gettext and libiconv) and decided to take the
latest-and-greatest gbs and merge in my package-specific mods. It was
quite a bit more difficult than it should have been given all the thrash
in the main gbs. Basically, EVERY package is a fork...
I eventually decided to NOT use the latest-and-greatest, but instead
used the version just before LOGGING support was added. And honestly, I
don't think I'll ever bother to up-merge again. That version of gbs
does everything I want and I see no need for "auto-edit README" or
"LOGGING support". If I want a log, I'll tee the output of configure or
make myself. Logs are for me, the maintainer...
Every new feature added to gbs makes it that much more difficult for
maintainers to keep pace with gbs updates when they update their
packages. Please think carefully before adding new stuff: is feature X
*really* worth it?
P.S. It'd be a different story if we were using an 'engine' with
external overrides, like mingwports or cgf's netrel(?) -- then mods to
the engine to provide new features would be distinct from the
package-specific overrides. But gbs ain't like that.