This is the mail archive of the cygwin-apps 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: generic-build-script extension to update version numbers in README


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.


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