Re: Stag and the Emdebian composite method.
On Wed, 2006-11-29 at 21:58 +0000, Neil Williams wrote:
> 1. The Stag addons in Emdebian SVN are quite a bit behind current
> Debian unstable: Stag is based on:
> debhelper 4.2.11
> dpkg 1.10.22
> Debian unstable, as of November 2006, has:
> debhelper 5.0.42
> dpkg 1.13.24
Well that would be m y fault as I did not really have time to update
that since I stopped being a student....
> 2. The Stag scripts use the emdebian/ directory ($DEBIAN_DIR) method.
> So I've done a few comparisons to see where the land lies with
> reference to the composite method proposed on the Wiki.
> These five scripts are modified only to the point of being emptied of
> content and made into placeholders. i.e. simply *not running* these
> scripts is directly equivalent to the Stag debhelper config as it is
> outlined in emdebian SVN.
> The five scripts are:
> I'd welcome any comments on this review from those with more experience
> of Stag, but it does look like a simple tweak of debian/rules that
> specifically comments out / removes these five scripts with a simple
> regular expression will be sufficient to simulate a Stag build. CDBS
> packages can be handled simply by substituting a cdbs ruleset that
> avoids running these scripts. Naturally, em_make would be able to do
> this for us so that emdebianising a Debian package achieves three tasks:
Sounds like you got it right! Stag was a basic idea that IMO is
overtaken by the current development and the new ideas.
> 1. Create an emdebian version string and a suitable entry in
> 2. Create the locale packages and entries in debian/control
> 3. Comment out/remove these five scripts from debian/rules or add the
> masking CDBS ruleset.
> Hopefully, this will dramatically reduce the size of the emdebian.diff
> patches to be held in SVN and the number of packages that will need any
> patches stored in SVN in the first place.
> I'll be looking at the dpkg code next, looking at what code may need to
> be implemented in emdebian scripts to handle differences between Debian
> and Stag.
I would drop Stag as it was. The work you have been doing lately is much
better and improves on the original idea. The way you are thinking now
and the work you are doing to implement this is just right on.