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

[Charles Wilson]

Igor Pechtchanski wrote:

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

At times I wish that I had originally stored all of my build scripts in 
a cvs repository.  If I imported the "official" generic-build-script as 
a "vendor branch", then I could more easily do a 'cvs merge -j 
vendor-release-27' within a workspace on the 'gettext' branch...

That would have made this a lot easier.  But now, it's just too much 
work to set up for all 30+ packages, so I keep on keeping on, 
hand-merging with every new release...

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

I too thought of a "regular" gbs and a single "maintainer-extras" 
script.  However, I suggested multiple fragments because it's 
open-ended.  We just keep adding more fragments to the master 
repository, and it's up to the end-user (e.g. package maintainers) which 
ones they actually download and use.  Or they can write their own. 
Maybe the "regular" gbs's 'maintainer-action' function can honor an 
environment variable, like CVSROOT: GBS_PATH=.:/usr/src/gbs-fragments or 
something.  That way, gbs can look in the specified locations for the 
proper fragments ('.' first for package-specific versions).

Sure, it's insecure as all heck, but if you're maintaining cygwin 
packages on a compromised machine...we've ALL got a problem!

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

See attached patch, which shows the changes from gbs-1.38 and 
gettext-0.14.5-1.  These changes were necessary to support:

1) four separate binary packages

2) two variant builds: "normal" and "relocatable".  I wanted both 
variants to be buildable with only minor changes to the buildscript 
(it's simply a 3 line change to the buildscript now)

3) The upstream maintainer is VERY specific about which files should go 
into the "runtime" package (cygwin's libintl3 + libgettextpo0 + gettext 
packages) and which files should go into the developer's package 
(cygwin's gettext-devel).  It's not a simple regex, but specific file 
listings.

4) The test suite CAN be run all at once -- but the rpath tests take 
over an hour.  I split them up into three different sets.

5) My modifications require bootstrapping.  To ease maintainance and 
avoid giant patches, I ship only the pre-autotool patches and run the 
bootstrap as part of the prep() phase.

6) I *also* run the boostrap in the -orig directory as part of the 
mkpatch() step.  Thus, I ship two patches: the pre-autotool one, and the 
post-autotool one (which SHOULD just be the contents of CYGWIN-PATCHES 
if I've done it right).

7) Since I've got two patches, I had to include them both in the 
checksig and spkg functions, along with their signatures.  (No, I don't 
actually sign anything, but it's all set up if someone more security 
obsessed were to take over my package)

BTW, the cvs buildscript is even worse: I have to keep track of which 
tests in the testsuite are known-to-fail, for two different test 
harnesses (local and pseudo-remote) -- because a failed test completely 
stops the suite.  No '-k' option!  Heck, even my simplest package, zlib, 
doesn't use the gbs directly; zlib is not autotool enabled so...

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

Well, the problem is, logging is a decorator: it decorates the existing 
functions.  Unless you want a whole new build-with-logging() function 
that has to be maintained in parallel with the regular build() function 
for package foo, I don't see how this particular feature can be moved 
out of the core gbs without getting REAL ugly: building cmd strings, 
possibly decorating _those_, and then eval'ing them.  Sad, really.

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

I know.  I'm just a curmudgeon.

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

Unfortunately, no -- because it's intrinsically tied in with spkg.  If 
we didn't need to actually SHIP the signatures, then we could move all 
signature-related stuff to an aux script.  But that kinda defeats the 
purpose.

   acceptpatch?

IMO, yes.  Ditto 'muck-with-readme', 'list', 'depends'.

  logging?

No, for reasons described above.  I'd *LOVE* to be wrong about this, but 
the only cures I see are worse than the disease.

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

Sure, with enough man-hours you can do anything you want.  But if it's 
hard for existing maintainers to keep up with the current incremental 
changes to gbs, it'll be durn near impossible to follow a wholesale 
architectural redesign.

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

You're still thinking that they are "private mods" as in 'tetchy little 
changes here and there'.  It's more like gbs is used as a base from 
which to massively fork, with wholesale rewriting of some of the 
functions. Maybe I'm just lucky in that my packages SUCK and everybody 
else gets to use the gbs unmodified, but not me.  I almost ALWAYS have 
to modify install(), for instance.  And any time I have to re-run the 
autotools, Katie bar the door...

The problem comes in when trying to 'upgrade' our fork to the ongoing 
development in the 'trunk'.  It really is a branch-and-merge-from type 
of operation.  Maybe I should give that local cvs mirror idea some more 
thought...

--
Chuck

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gettext-gbs.diff
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20051119/4af57211/attachment.ksh>