[buildd-tools-devel] re buildd's resolver and package's build deps

[Roger Leigh]

On Wed, Feb 23, 2011 at 12:38:34PM +0100, Philipp Kern wrote:
> On Wed, Feb 23, 2011 at 11:30:05AM +0000, Roger Leigh wrote:
> > I've now implemented this with the attached patch.  If you are happy
> > with this behaviour, I'll commit it.  Those six lines are equivalent
> > to about 300 in the internal resolver!  With this change made, would
> > you be OK to consider moving over to the apt resolver on the buildds?
> > At this point it's pretty much identical in every way that matters,
> > certainly from empirical testing.
> 
> Apart from the usual "stuff will break when we merge the branch" issue, yes.
> And buildd needs to get some touches to support resolve-alternatives.

To avoid the issues we have had in the past with the buildd branch,
I have repeated what you did with the buildd-0.60.0 branch, and
created a buildd-0.61.0 branch.  This will mean the buildd branch
will never need to have new stuff from master merged into it, there
will be one per stable release, so it won't break badly like before.
When there's a new stable release, we can just create a new
buildd-$release branch and merge the changes from the old one.  This
should make life *much* easier.  Cherry-picking fixes from master
will be trivial, and we won't get into the state where we have to
be in lock-step with master doing a merge both ways to sync them up,
as happened previously.

This will mean we use one as a production branch, and then be using
the newer one for testing prior to deployment, and what's going on
on master won't affect either.  Does this sound acceptable to you?

The new buildd-0.61.0 includes all the changes on the current
buildd-0.60.0 branch, which were merged back onto master.  The only
change it currently has is to enable compatibility features for
lenny.  However, note that the Dpkg::Deps usage requires squeeze,
so we will have to either upgrade the buildds prior to deploying it,
or I can merge the Dpkg::Deps backport into sbuild that's currently
on the buildd-merge2 branch.  The latter is a bit icky, but does work
just fine if you want to keep the buildds on lenny for some time.

This version of sbuild has been tested extensively, having been used
for the whole archive rebuilds, and includes the fixes found from that
testing.  However, the buildd part has not been tested, and could do
with some testing if you have the time.  The main change there has been
with the configuration, which switched from using inheritance of the
Sbuild::ConfBase object to just manipulating a ConfBase instance, which
makes things somewhat simpler when multiple modules are creating
configuration objects (no hacky workarounds needed to share stuff now).
I think it should be just fine, but it could use some testing.

> (The backwards compatible way would be, for buildd, resolve-alternatives=true
> for resolver=aptitude and false and resolver=apt for the case where none's
> specified, i.e. previously internal.)

Does buildd currently assume this behaviour, i.e. does it know which
resolver is in use?  If so, why does it need this knowledge?  I can see
wanna-build finding it useful for dep-wait determination.  In fact,
we could get buildd to use sbuild to test if the dependencies are
resolvable using the build chroot without installing anything, so that
the resolver logic is contained in just one place.  If it would be
helpful, we can allow selection on the command line, so buildd can
force use of a particular resolver.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110223/95990ad8/attachment-0001.pgp>