[buildd-tools-devel] testers wanted: sbuild and build-dependencies

[Roger Leigh]

On Wed, Nov 10, 2010 at 08:57:35PM +0100, Goswin von Brederlow wrote:
> Roger Leigh <rleigh at codelibre.net> writes:
> 
> > On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote:
> >> Roger Leigh <rleigh at debian.org> writes:
> > Just to mention in passing, I also wrote an additional "apt"
> > resolver last night, based on the aptitude resolver, which works
> > in exactly the same way.  Not usable under all circumstances yet,
> > but also available (in git only at present) for testing.  The
> > main issue with apt is getting "apt-get -yf install" to not choose
> > to remove the dependency package as a solution!  Currently looking
> > at the possibilities here--any thoughts welcome!
> 
> Does that actually happen in cases where another solution would keep it?
> 
> There is a solution to this actually. Create a Packages, Release and
> Release.gpg file for the pseudo package and add them as file:// url to
> sources.list.d/. Then just apt-get install pseudo-package.

I'll give that a go, thanks.

> >> This destroys the determinicity of build dependencies. So if I say
> >> 
> >>   Build-Depends: lib-new-name | lib-old-name
> >> 
> >> so the package builds (for users) in both stable/testing and unstable it
> >> is no longer given which library is used by the unstable buildds. Some
> >> will pick lib-new-name and some, where the new lib isn't compiled yet,
> >> lib-old-name. And so on.
> >> 
> >> I always heard determinicity was a wanted feature for the buildds.
> >
> > It is, and this is something to look at carefully.  In the example
> > above, this is a very real problem (which could be rectified by
> > having stricter build-deps).
> >
> > The root problem here is that at any given moment in time, unstable
> > is not in a consistent state--packages may be outdated on several
> > architectures, and so a package build may use (and depend on)
> > different versions in different architectures.  There are several
> > places this could be fixed:
> >
> > • we could keep packages out of the archive until built on all
> >   architectures.
> > • we could dep-wait a package until all its deps are the same
> >   across all architectures
> 
> That is called testing. And for anything doing a library transition that
> obviously won't work or migration to testing wouldn't be such big
> problem all around.

I was considering this earlier, and had this idea:

testing migration currently conflates two separate criteria when
considering suitability for migration:

• the package is built on all architectures
• the package meets certain quality criteria such as bugginess, state
  of freeze, age since upload, etc.

Consider that if these two criteria were split into migrations
between separate distributions with the addition of a third
distribution, which I'll call "pre-unstable" (equivalent to current
unstable) in this example:

      upload → pre-unstable
pre-unstable → unstable     [migration when built on all arches]
    unstable → testing      [migration when quality critera met]

That is to say, "unstable" is entirely self-consistent in containing
the same binaries across all architectures (where applicable).
Binaries are only present here when built on all suitable
architectures.  

If "pre-unstable" sources were autobuilt using the "unstable" binaries,
it would ensure that the available binaries are identical across all
architectures.  "pre-unstable" is just a means of collecting binary
uploads until it's uploaded for all arches, at which point it can
migrate to unstable (which is a half-way house between current unstable
and testing).  The pre-unstable → unstable migration can also avoid the
package dependency checks to migrate sets of packages used for testing
migrations; the only point is to ensure unstable binaries are consistent
across arches so the autobuilders always build against the same
package set on all arches.

I guess from a technical POV, this isn't too hard to do.  The
"pre-unstable" need not even be mirrored--it's just an internal
implementation detail--buildds upload here rather than directly to
unstable.


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: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101110/e0f66e4d/attachment.pgp>