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


On Fri, 18 Nov 2005, Charles Wilson wrote:

> 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'?

At the time I've thought long and hard about integrating more features.
The original argument for including them was to allow the maintainers to
release packages with minor modifications of the g-b-s (mostly to set
parameters).  And this worked for most *new* packages (though I agree that
the maintainer-only features are getting clunky).  It probably won't work
for any package that has a more sophisticated build procedure.  Perhaps
it's time to rethink this.

> It's a nice feature, but how useful is it, really?  Ditto this
> maintainer-only 'muck with the README' script.

BTW, the "muck with the README" idea isn't new -- I still have a link to
an unapplied patch from last February that does essentially that (and
more).  That patch was dubbed too complex, and the original submitter
never followed up.

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

FWIW, I like this idea.  A lot.  Maybe we should have only *one* ancillary
script that contains all maintainer-only features.  That way,

  ./foo.sh maintainer-action update-readme

would do what you said (say, use the 'update-readme' function from a local
'maintainer.sh', or pass the 'update-readme' option to some function that
would properly dispatch it, or even fetch the proper 'maintainer.sh'
version from CVS on sourceware.org and eval it).  That way, the package
maintainers would have less to worry about, since the core g-b-s would not
change all that often.

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

Yes, but there's the question of the extent to which it has diverged.  If
all you do is change parameters, it ought to be easy.  It would help if
you outlined the difficulties you had (feel free to email me privately,
though I think a public summary might produce more patches).

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

Heh, the argument for including the logs (which I, after having installed
some package source tarballs, think aren't such a hot idea anymore) was
that when users build the packages on their machines, they can see if they
get a different configuration from what the maintainer had.  And it may be
a useful feature to run the build with logging turned on (though I don't
think it should be the default).  Perhaps another job for an external
maintainer.sh script.

> 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?

True enough, though this is the first official complaint from an active
package maintainer about the new features.

Let me try to find some time (probably in a couple of weeks) to extract
the non-core features of the g-b-s into a separate script (tentative name:
"maintainer-only-features.sh", suggestions welcome).  In the meantime,
another thing that would help is defining the "core g-b-s" features.  Is
anyone using the package signature feature?  acceptpatch?  logging?

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

What's stopping us from trying to get there?  Anything specific to the
nature of the g-b-s?  One way to address this may be defining more
functions like "unpack()" to contain the pluggable/overridable behavior.

There was also Jari Aalto's build script (I forget the name) which had
some of the above properties, IIRC.

BTW, thanks for your comments, Chuck.  I'm afraid I lost sight of the fact
that many maintainers have private mods to the g-b-s, and that feature
updates may cause them trouble.  We should definitely rectify this.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA


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