On Wed, Nov 10, 2010 at 2:57 PM, Goswin von Brederlow <goswin-...@web.de> wrote: > Roger Leigh <rle...@codelibre.net> writes: > >> On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote: >>> Roger Leigh <rle...@debian.org> writes: >>> >>> > A new "aptitude" resolver has been written by Marc 'HE' Brockschmidt. >>> > This creates a dummy "dependency package" which is installed and >>> > contains Depends and Conflicts for all the appropriate Build-Depends >>> > and Build-Conflicts, and uses aptitude to install and remove the >>> > appropriate packages to satisfy them. This has been in use on our >>> > experimental buildds for about a year, and we now want to look towards >>> > making it the default. However, we need some more widespread testing >>> > to make sure the dependency resolving doesn't result in inconsistent >>> > installation of packages and hence inconsistent library dependencies >>> > or break building of any packages etc. >>> >>> Yet another or did he take the one from pbuilder? >> >> It's new, but based upon the ideas in pbuilder. >> >> 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.
Another solution is to create a Sources file and use the 'build-dep' command from apt-get or aptitude. >>> 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. > > Don't forget this not only happens when a package itself differs between > arch. This can also happen if any of the recursive depends differs. On > one arch lib-new-name can exist but be uninstallable while on another it > is installable. > >> • we could keep the current approach of banning alternatives >> entirely (but note that this does not solve the entire problem, >> it's still easy to get inconsistency anyway) >> >> The existing approach to determinism is not to support alternatives >> at all, which is clearly not ideal. While I don't think we should >> be encouraging the use of alternative build-deps, this is one of the >> most commonly reported bugs in sbuild--there are valid use cases for >> them. > > Actually alternatives are supported. Most notably in A [i386] | B > [!i386]. Sbuild fixates on the first alternative that should be > installable. That makes it 100% perdictable to the uploader which > package he gets. This use of alternatives will fail on non-i386 machines using sbuild's internal build-dep resolver. It will succeed using apt or aptitude however. Here's an example for anyone willing to try. It doesn't matter if the architecture restrictions are there or not. Build-Depends: linux-headers-2.6-i386 [i386] | linux-headers [!i386] >> All the modern buildds are based around snapshotting the build chroot, >> which gives us a clean slate at the start of each build. Providing we >> have a common base environment across all our buildds, this should >> provide a measure of stability--I don't think any of the existing >> resolvers choose packages randomly--so the resolver should pick the >> same package sets across architectures so long as the available >> packages are the same. Now, this might not always be true, but this >> also affects the existing resolver as well. Not letting binary >> packages enter unstable until built on all architectures would be a >> solution to this. I'd have to say, solving the problem at its root, >> and giving our tools more flexibility would be the ideal outcome. > > Problem is packages aren't the same and enforcing sameness causes too > much delay and deadlocks. Just look at testing. > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/87hbfpx87k....@frosties.localnet > > -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimg9mm10qs9odxu-a-xntdbhmgsmg8y=khrh...@mail.gmail.com