On Wed, Nov 10, 2010 at 08:57:35PM +0100, Goswin von Brederlow wrote: > Roger Leigh <firstname.lastname@example.org> writes: > > > On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote: > >> Roger Leigh <email@example.com> 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.
Description: Digital signature