Andres Mejia <mcita...@gmail.com> writes: > 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.
Can use a unsigned Sources file here? Would 'apt-get build-dep foo=version' complain about it being unsigned? It isn't installing any debs from it, it only gets the list of deb from it. So I guess that should work without Release.gpg file. >>>> 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] Well, it does seem to work fine on buildds: Package: coinor-csdp Build-Depends: cdbs, debhelper (>= 7), texlive-latex-base, libatlas-base-dev [!powerpc !alpha !arm !armel !sh4] | libblas-dev, liblapack-dev https://buildd.debian.org/fetch.cgi?pkg=coinor-csdp&arch=alpha&ver=6.1.1-1&stamp=1270872592&file=log&as=raw Checking for already installed source dependencies... cdbs: missing debhelper: missing Using default version 7.4.17 texlive-latex-base: missing libblas-dev: missing liblapack-dev: missing On alpha it ignores the libatlas-base-dev and installs libblas-dev as it should. So alternatives aren't 100% ignored. 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/877hgk1agj....@frosties.localnet
