generic-build-script extension to update version numbers in README

[Charles Wilson]

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?

--
Chuck

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.