FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-21-2011, 07:04 AM
Roger Leigh
 
Default Wanted: system/volunteer to do whole-archive rebuild (×3) to test sbuild

On Mon, Feb 14, 2011 at 11:36:55PM +0000, Roger Leigh wrote:
> sbuild, which does the job of building binary packages on our buildds,
> uses a built-in build-dependency resolver ("internal") to work out
> what packages need installing/removing in order to satisfy a package's
> Build-Depends and Build-Conflicts. Unfortunately, this has a number
> of bugs, e.g. #403246, as well as serious maintainability issues which
> make it less than desirable. Last year, we introduced two new
> resolvers, "apt" and "aptitude" which delegate the somewhat complex
> build dependency resolving to the tools which are best at it.
>
> Now that squeeze is out, it would be great if we could revisit the
> discussion about which build dependency resolver we want to use on
> our buildds. The main concern here is that switching resolvers will
> change exactly which packages are installed in some situations, mainly
> in the case of packages depending on alternatives, which could lead to
> different packages being installed, inconsistent selection of packages
> being installed, or broken package builds. The intenal resolver was
> dumb: it just always chose the first dependency even if it was
> unsatisfiable. aptitude is far cleverer; apt somewhere in between,
> though we've tweaked aptitude to behave as close to stupid as we can.

The results of this are below. Many thanks to Tollef Fog Heen for
his kind donation of time on one of his big machines to run three
archive rebuilds. A better quality PDF version is attached.

Due to the size limits of the lists, the full version is at
http://people.debian.org/~rleigh/squeeze-rebuild/report.pdf

Regards,
Roger


sbuild Build Dependency Resolver Comparison


1. Introduction

sbuild has three different build dependency resolvers,
internal, apt and aptitude. The historical default is
internal, while apt and aptitude are much newer. The inter‐
nal resolver is a build‐dependency resolver implemented
directly in Perl, and which has a number of deficiencies
mainly relating to newer additions to the dependency format,
and also in resolving of complex versioned and virtual
dependencies. The apt and aptitude resolvers delegate
almost all dependency resolution to the apt and aptitude
tools, whose dependency resolution is far more capable and
better tested. However, the strict, simple, predictable
dependency resolution provided by internal must also be pro‐
vided by the alternative resolvers in order for them to be
suitable for use on our build dæmons.

A goal for the wheezy release is to replace the inter‐
nal resolver with one of the apt or aptitude resolvers.
However, we had no hard information upon which to base a
decision. I have consequently rebuilt the entire Debian ar‐
chive three times using the internal, apt and aptitude
resolvers, using the squeeze release since it’s stable and
unchanging between the runs. The build logs have been pro‐
cessed and the build status and dependency information
inserted into a PostgreSQL database in order to allow direct
comparison of the behaviour of the three resolvers.

These tests all used the current version of sbuild from
unstable (0.60.9‐1), with a one line patch to the aptitude
resolver to make it use the same dpkg options as the other
resolvers when installing packages. The internal resolver
has a bugfix the version on the buildds does not yet have,
allowing it to delegate virtual dependency resolution to
apt‐get rather than failing outright (since older versions’
handling of virtual packages was completely broken).

Many thanks to Tollef Fog Heen and freedesktop.org for
the use of a big machine on which to do the builds. This 24
core beast was able to rebuild the entire archive in 14
hours, taking four days in total for the three builds.

The build logs, database schema and database dump are
all available at http://people.debian.org/~rleigh/squeeze‐
rebuild/.


2. Build summary

These are the summary statistics for all the builds:


┌─────────┬───── ──────┬───────── ────┬───────┐
│Resolver │ Status │ Fail stage │ Count │
├─────────┼───── ──────┼───────── ────┼───────┤
│apt │ attempted │ build │ 38 │
│apt │ given‐back │ install‐deps │ 5 │
│apt │ skipped │ arch‐check │ 6195 │
│apt │ successful │ │ 8372 │
├─────────┼───── ──────┼───────── ────┼───────┤
│aptitude │ attempted │ build │ 41 │
│aptitude │ skipped │ arch‐check │ 6195 │
│aptitude │ successful │ │ 8374 │
├─────────┼───── ──────┼───────── ────┼───────┤
│internal │ attempted │ build │ 37 │
│internal │ given‐back │ install‐deps │ 16 │
│internal │ skipped │ arch‐check │ 6195 │
│internal │ successful │ │ 8362 │
└─────────┴───── ──────┴───────── ────┴───────┘

Skipped packages failing the architecture check are
Architecture: all packages; these were all skipped by the
different resolvers prior to installation of build dependen‐
cies, and will not be considered further. Packages were
given back due to errors during installation of build depen‐
dencies, and comprised:


┌─────────┬───── ──────────────── ──────────────── ────┐
│Resolver │ Build │
├─────────┼───── ──────────────── ──────────────── ────┤
│apt │ circlepack_5.1‐7 │
│apt │ libcomplearn‐mod‐ppmd_1.0.7‐2 │
│apt │ libcomplearn‐mod‐ppmdx_1.0.7‐2 │
│apt │ linux‐modules‐di‐amd64‐2.6_1.23 │
│apt │ xserver‐xorg‐video‐glide_1.0.3‐2+squeeze1 │
├─────────┼───── ──────────────── ──────────────── ────┤
│internal │ allegro4.2_2:4.2.2‐2.2 │
│internal │ arts_1.5.9‐3 │
│internal │ cheesetracker_0.9.15.3‐4 │
│internal │ circlepack_5.1‐7 │
│internal │ djplay_0.5.0‐3.1 │
│internal │ dovecot_1:1.2.15‐4 │
│internal │ ecasound2.2_2.7.0‐1.1 │
│internal │ galan_0.3.0+beta4‐2 │
│internal │ libcomplearn‐mod‐ppmd_1.0.7‐2 │
│internal │ libcomplearn‐mod‐ppmdx_1.0.7‐2 │
│internal │ libvisual‐plugins_0.4.0.dfsg.1‐2 │
│internal │ linux‐modules‐di‐amd64‐2.6_1.23 │
│internal │ specimen_0.5.2rc3‐1.1 │
│internal │ t38modem_1.2.0‐1 │
│internal │ timemachine_0.3.0‐3 │
│internal │ xserver‐xorg‐video‐glide_1.0.3‐2+squeeze1 │
└─────────┴───── ──────────────── ──────────────── ────┘

circlepack, libcomplearn‐mod‐ppmd, libcomplearn‐mod‐
ppmdx, linux‐modules‐di‐amd64 and xserver‐xorg‐video‐glide
were not built by either the apt or internal resolvers
because the needed build dependencies were unavailable.
They did build not build with aptitude either, but the apti‐
tude failure did not terminate the build; these are reported
as attempted builds because failure occurs when dpkg‐build‐
package notices the build dependencies are not satisfied.
This will require fixing in the aptitude resolver.

allegro, arts, cheesetracker, djplay, ecasound2, galan,
libvisual‐plugins, specimen and timemachine all have build
dependencies upon libjack_0.100.0‐dev which is a virtual
package. The internal resolver can not resolve virtual
dependencies, while the other resolvers can. These packages
should be fixed to use libjack‐dev.

dovecot (bug filed), steghide (already fixed in unsta‐
ble) and t38modem (bug filed) have a versioned build con‐
flict upon linux‐kernel‐headers which causes the internal
resolver to purge build‐essential and the whole toolchain,
which causes build failure. This isn’t a problem with the
build‐conflict being incorrect, though a conflict on linux‐
kernel‐headers (<< 2.5.999‐test7‐bk‐14) is certainly useless
and outdated, this is a bug in the internal resolver. How‐
ever, the build conflict is outdated; given that we only
support linux >= 2.6, so it can be safely removed. The more
advanced apt and aptitude resolvers could cope with the ver‐
sioned virtual conflict.

Attempted (failed) builds failed during building with
dpkg‐buildpackage, and were the same for all resolvers,
allowing for differences in dependency resolution failure.

3. Methodology

In order to allow for meaningful comparisons between
resolvers, only builds which were successful with all three
resolvers will be compared in the following sections. The
apt and aptitude resolvers install additional packages in
order to function, which require excluding from the compar‐
isons. Both the apt and aptitude resolvers install dummy
dependency packages in order to delegate resolving to the
apt or aptitude programs, which should not be included in
the differences between the resolvers. Additionally, the
aptitude resolver requires aptitude, and its package depen‐
dencies, to be installed, and these also require exclusion.
By removing these known differences, only the unknown dif‐
ferences will show up.

Using SQL set difference (EXCEPT), the packages
installed only when using the internal resolver, or only
when using the apt (or apt resolver) can be compared; pack‐
ages installed in both situations will be ignored. NOT IN
will be used to remove unwanted resolver and dependency
packages. The database schema, views and queries used to
analyse the data, together with the scripts used to perform
the builds and parse the build logs to get the data to
insert into the database are in the appendix at the end of
this document.


4. Differences between internal and apt

A total of 54 out of 8345 successful builds (0.65%)
showed discrepancies in the installed package set.

[Detail removed]

5. Differences between internal and aptitude

A total of 55 out of 8345 successful builds (0.66%)
showed discrepancies in the installed package set.

[Detail removed]

6. Differences between apt and aptitude

The package sets installed by apt and aptitude were
almost identical. Only two packages out of 8345 successful
builds (0.02%) showed discrepancies in the installed package
set.

Packages installed with internal and apt (not apti‐
tude):


┌─────────────── ┬─────────────── ───────────┐
│Build │ Package │
└─────────────── ┴─────────────── ───────────┘
│tulip_3.1.2‐2.3 │ libdrm2_2.4.21‐1~squeeze3 │
│ │ libxdamage1_1:1.1.3‐1 │
│ │ libxfixes3_1:4.0.5‐1 │
│ │ libxxf86vm1_1:1.1.0‐2 │
└─────────────── ┴─────────────── ───────────┘

Packages installed with internal and aptitude (not
apt):


┌─────────────── ┬─────────────── ──────┐
│Build │ Package │
└─────────────── ┴─────────────── ──────┘
│piklab_0.15.7‐1 │ libsqlite3‐0_3.7.3‐1 │
└─────────────── ┴─────────────── ──────┘


7. Analysis of resolver differences

alex_2.3.3‐1

apt and aptitude install docbook_4.5‐4.

Depends on docbook‐utils, docbook‐xsl and docbook‐xml.
docbook is only suggested, and there is an alternative
dependency in docbook‐dsssl. apt‐get and aptitude behave
differently when installing a dependency via the dummy pack‐
age than they do when invoked directly as internal does.
When invoked with a list of packages to install, docbook is
not installed, presumably because the alternative dependency
is already satisfied.

avogadro_1.0.1‐3

internal installs sip4_4.10.2‐1.

sip4 is a transitional package. apt and aptitude are
intelligent enough to realise that this is provided by
another package and not install it, whereas internal is not.

boxbackup_0.11~rc2‐7squeeze1

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

calibre_0.7.7+dfsg‐1squeeze1

internal installs sip4_4.10.2‐1.

Same reason as for avogadro.

coinor‐cbc_2.5.0‐2

apt and aptitude install libatlas‐base‐dev_3.8.3‐27 and
libatlas‐dev_3.8.3‐27.

This is an alternative dependency in liblapack‐dev. It
can be satisfied by libblas‐3gf.so provided by libblas‐dev.
internal doesn’t pick both alternatives, while apt and
internal do.

ecj_3.5.1‐1

internal installs ca‐certificates_20090814+nmu2, ca‐
certificates‐java_20100412, default‐jre‐headless_1:1.6‐40,
liblcms1_1.18.dfsg‐1.2+b3, libnspr4‐0d_4.8.6‐1, lib‐
nss3‐1d_3.12.8‐1, openjdk‐6‐jre‐headless_6b18‐1.8.3‐2, open‐
jdk‐6‐jre‐lib_6b18‐1.8.3‐2, openssl_0.9.8o‐4 and tzdata‐
java_2010o‐1

This is a redundant set of packages pulled in via the
ant build dependency, which has a complex set of four possi‐
ble alternatives. apt and aptitude realise that this is
satisfied by gcj‐4.4‐jdk, and do not install them.

elinks_0.12~pre5‐2

internal installs docbook_4.5‐4.

The build dependency docbook‐utils depends upon doc‐
book‐dsssl which in turn depends upon either docbook or doc‐
book‐xml. When run via apt‐get or aptitude directly, doc‐
book is installed, and when installed via a dependency pack‐
age, it is not.

enblend‐enfuse_4.0+dfsg‐1

apt and aptitude install ttf‐dejavu‐core_2.31‐1.

The fontconfig‐config dependency has alternative depen‐
dencies upon four different font packages. internal
realises that they are already satisfied, whereas apt and
aptitude do not.

f‐spot_0.6.2‐2

apt and aptitude install automake_1:1.11.1‐1.

The build dependency intltool has an alternative depen‐
dency on automake or automaken. Consequently, apt and apti‐
tude install two versions of automake, and internal only
one.

gdcm_2.0.16‐2


apt and aptitude install gcj‐4.4‐base_4.4.5‐2,
gcj‐4.4‐jre_4.4.5‐2, gcj‐4.4‐jre‐headless_4.4.5‐2, gcj‐
jre_4:4.4.5‐1, gcj‐jre‐headless_4:4.4.5‐1, libgcj10_4.4.5‐2,
libgcj10‐awt_4.4.5‐2 and libgcj‐common_1:4.4.5‐1.

Possible alternatives affecting this are default‐jdk
and libvtk‐java. This is again a case of choosing multiple
alternatives.

gjiten_2.6‐2.1

internal installs docbook_4.5‐4.

Same reason as for elinks.

gmime2.2_2.2.25‐2

internal installs libosp5_1.5.2‐8,
libostyle1c2_1.4devel1‐19 and openjade_1.4devel1‐19.

Multiple docbook possibilities via alternatives in doc‐
book‐dsssl and gtk‐doc‐tools.

gmime2.4_2.4.14‐1+nmu1

internal installs libosp5_1.5.2‐8,
libostyle1c2_1.4devel1‐19 and openjade_1.4devel1‐19.

Same reasons as for gmime2.2.

gnome‐color‐manager_2.30.2‐1

internal installs libosp5_1.5.2‐8,
libostyle1c2_1.4devel1‐19 and openjade_1.4devel1‐19.

Same reasons as for gmime2.2.

gridengine_6.2u5‐1

internal installs default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

happy_1.18.4‐2

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

hardware‐monitor_1.4.2‐1.1

apt and aptitude install makedev_2.3.1‐89.

Alternative dependency in libsensors4 build dependency.

hplip_3.10.6‐2

apt and aptitude install udev_164‐3, while internal
installs makedev_2.3.1‐89.

Same reason as for hardware‐monitor.

iceweasel_3.5.16‐4

apt and aptitude install ttf‐dejavu‐core_2.31‐1.

Same reason as for enblend‐enfuse.

idzebra_2.0.44‐2

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

java3d_1.5.2+dfsg‐5

internal installs default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

jblas_1.1.1‐2

internal installs default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

k3d_0.8.0.2‐6

apt and aptitude install ttf‐dejavu‐core_2.31‐1.

Same reason as for enblend‐enfuse.

libjdic‐java_0.9.5‐7

apt and aptitude install default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

libjogl‐java_1.1.1+dak1‐9

internal installs default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

libraw1394_2.0.5‐2

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

nut_2.4.3‐1.1squeeze1

apt and aptitude install makedev_2.3.1‐89.

Same reasons as for hardware‐monitor.

openmeeg_2.0.0.dfsg‐2

apt and aptitude install liblapack3gf_3.2.1‐8.

Same reasons as for coinor‐cbc.

openoffice.org_1:3.2.1‐11+squeeze2

internal installs default‐jre‐headless_1:1.6‐40.

Same reasons as for ecj.

opensp_1.5.2‐8

internal installs docbook_4.5‐4.

Same reason as for elinks.

openturns_0.13.2‐8

apt and aptitude install libatlas3gf‐base_3.8.3‐27,
libatlas‐base‐dev_3.8.3‐27 and libatlas‐dev_3.8.3‐27.

Same reasons as for coinor‐cbc.

ounit_1.0.3‐5

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

pauker_1.8+dfsg‐4

apt and aptitude install default‐jre_1:1.6‐40.

Same reasons as for ecj.

phaseshift_0.40‐13.2

internal installs xlibmesa‐gl‐dev_1:7.5+8.

This package is transitional. apt and aptitude are
clever enough to skip it, while internal uses the first
dependency.

php5_5.3.3‐7

internal installs libdb‐dev_4.8.

Another transitional‐like package where apt and apti‐
tude pick the direct dependency rather than using a meta‐
package.

piklab_0.15.7‐1

internal and aptitude install libsqlite3‐0_3.7.3‐1.

internal installs libasyncns0_0.3‐1.1, lib‐
cap2_1:2.19‐3, libflac8_1.2.1‐2+b1,
libphonon4_4:4.6.0really4.4.2‐1, libpulse0_0.9.21‐3+b1,
libpulse‐mainloop‐glib0_0.9.21‐3+b1, libqt4‐assis‐
tant_4:4.6.3‐4, libqt4‐dbus_4:4.6.3‐4,
libqt4‐designer_4:4.6.3‐4, libqt4‐dev_4:4.6.3‐4,
libqt4‐help_4:4.6.3‐4, libqt4‐multimedia_4:4.6.3‐4,
libqt4‐network_4:4.6.3‐4, libqt4‐qt3support_4:4.6.3‐4,
libqt4‐script_4:4.6.3‐4, libqt4‐scripttools_4:4.6.3‐4,
libqt4‐sql_4:4.6.3‐4, libqt4‐svg_4:4.6.3‐4,
libqt4‐test_4:4.6.3‐4, libqt4‐webkit_4:4.6.3‐4,
libqt4‐xml_4:4.6.3‐4, libqt4‐xmlpatterns_4:4.6.3‐4, libqt‐
core4_4:4.6.3‐4, libqtgui4_4:4.6.3‐4, libsndfile1_1.0.21‐3,
libwrap0_7.6.q‐19, libxtst6_2:1.1.0‐3 and
qt4‐qmake_4:4.6.3‐4

The package has an (arguably buggy) alternative build
dependency on both libqt4‐dev or libqt3‐mt‐dev. internal
installs both sets; apt and aptitude choose to only install
a single set. libsqlite3‐0 is pulled in via a very indirect
dependency, probably somewhere within the Qt libraries.

plplot_5.9.5‐4

apt and aptitude install ttf‐dejavu‐core_2.31‐1.

Same reason as for enblend‐enfuse.

poker‐network_1.7.7‐3.2

internal installs apache2.2‐bin_2.2.16‐6,
apache2.2‐common_2.2.16‐6, apache2‐mpm‐prefork_2.2.16‐6,
apache2‐utils_2.2.16‐6, libapache2‐mod‐php5_5.3.3‐7,
libapr1_1.4.2‐6, libaprutil1_1.3.9+dfsg‐5, libaprutil1‐dbd‐
sqlite3_1.3.9+dfsg‐5, libaprutil1‐ldap_1.3.9+dfsg‐5, lib‐
cap2_1:2.19‐3, libldap‐2.4‐2_2.4.23‐7, lib‐
sasl2‐2_2.1.23.dfsg1‐7 and procps_1:3.2.8‐9

Incredibly, these are all pulled in via libapache2‐mod‐
php5 through one of the php5 build dependencies (I still
haven’t fathomed which).

qmtest_2.4.1‐1

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

qtiplot_0.9.8‐1

internal installs docbook_4.5‐4, python‐
sip4‐dev_4.10.2‐1 and sip4_4.10.2‐1.

Same reason as for elinks for docbook, and as for avo‐
gadro for sip4.

rhythmbox_0.12.8‐3

libosp5_1.5.2‐8, libostyle1c2_1.4devel1‐19 and open‐
jade_1.4devel1‐19.

Same reasons as for gmime2.2.

rss‐glx_0.9.1‐3

internal installs libdrm2_2.4.21‐1~squeeze3 and
libxxf86vm1_1:1.1.0‐2.

This package has a number of alternative OpenGL build
dependencies. internal will only ever pick libgl1‐mesa‐
swx11‐dev, while apt and aptitude may pick one of the others
which does not include these packages.

scalapack_1.8.0‐6

apt and aptitude install libatlas3gf‐base_3.8.3‐27,
libatlas‐base‐dev_3.8.3‐27 and libatlas‐dev_3.8.3‐27.

Same reasons as for coinor‐cbc.

scidavis_0.2.4‐1

internal installs python‐sip4‐dev_4.10.2‐1.

Same reason as for avogadro.

shared‐mime‐info_0.71‐4

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

subversion_1.6.12dfsg‐4


internal installs ca‐certificates‐java_20100412,
default‐jre_1:1.6‐40, default‐jre‐headless_1:1.6‐40, libac‐
cess‐bridge‐java_1.26.2‐5, libaccess‐bridge‐java‐
jni_1.26.2‐5, libnspr4‐0d_4.8.6‐1, libnss3‐1d_3.12.8‐1,
openjdk‐6‐jre_6b18‐1.8.3‐2, openjdk‐6‐jre‐head‐
less_6b18‐1.8.3‐2, openjdk‐6‐jre‐lib_6b18‐1.8.3‐2 and
tzdata‐java_2010o‐1.

Multiple alternatives via junit.

taskjuggler_2.4.3‐2

apt and aptitude install opensp_1.5.2‐8.

There are a number of DocBook build dependencies con‐
taining alternative dependencies leading to multiple solu‐
tions.

thuban_1.2.2‐2

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.

tig_0.16‐2

internal installs docbook_4.5‐4.

Same reason as for elinks.

trackballs_1.1.4‐4

internal installs xlibmesa‐gl‐dev_1:7.5+8.

Package contains an alternative build dependency upon
xlibmesa‐gl‐dev and libgl‐dev.

ttt_1.7‐3.2

internal installs fontconfig‐config_2.8.0‐2.1, libex‐
pat1_2.0.1‐7, libfontconfig1_2.8.0‐2.1,
libfreetype6_2.4.2‐2.1, libxext6_2:1.1.2‐1,
libxft2_2.1.14‐2, libxrender1_1:0.9.6‐1, libxss1_1:1.2.0‐2,
tcl8.5_8.5.8‐2, tk8.5_8.5.8‐1, ttf‐dejavu‐core_2.31‐1 and
ucf_3.0025+nmu1.

The build dependency blt‐dev depends on both versions
8.4 and 8.5 of tcl and tk. The internal resolver decides to
install both versions, whereas apt and aptitude do not.

tulip_3.1.2‐2.3

internal and apt install libdrm2_2.4.21‐1~squeeze3,
libxdamage1_1:1.1.3‐1, libxfixes3_1:4.0.5‐1 and
libxxf86vm1_1:1.1.0‐2.

Multiple alternative dependencies in build dependency
libqt4‐opengl‐dev and libosmesa6‐dev.

xmakemol_5.16‐5

internal installs libdrm2_2.4.21‐1~squeeze3, libxdam‐
age1_1:1.1.3‐1, libxfixes3_1:4.0.5‐1 and
libxxf86vm1_1:1.1.0‐2.

Multiple possible OpenGL solutions, as for previous
examples.

xplanet_1.2.1‐3 apt and aptitude install ttf‐dejavu‐
core_2.31‐1.

Same reason as for enblend‐enfuse.

yaz_4.0.11‐1

apt and aptitude install docbook_4.5‐4.

Same reason as for alex.


8. Identified differences between resolvers

The differences observed in all of the packages in the
previous section have the same root cause. The method of
installing build dependencies

internal invokes apt‐get with the argument install and
then a list of dependencies to install, then repeats this
with remove with a list of conflicts to remove. apt and
aptitude invoke apt‐get or aptitude, respectively, with an
install argument and a dummy dependency package containing
the complete set of depends and conflicts. Both apt‐get and
aptitude behave slightly differently if the package list is
provided on the command line or as a dependency package.
The build dependencies requested will be installed, but
depending upon indirect alternative dependencies, there may
be additional packages installed (or not) depending upon the
solution found. The alex and elinks packages, above, demon‐
strates this with each having two alternative solutions for
the DocBook dependencies. Note that neither solution is
incorrect; both are technically correct solutions.

The same different behaviour when faced with multiple
alternatives applies to all the other packages. Only a cou‐
ple of cases are directly due to alternative dependencies
directly in the build dependencies; all other cases are
indirect, in the dependencies of dependencies.

· The OpenGL library dependencies are overly complex;
these could use some simplification.

· The same situation exists with the multiple Java alter‐
natives, and differing ordering in different packages.
Again, some simplification is in order.

· And the same situation exists for DocBook; there are
just too many solutions to give consistent results.

The apt and aptitude resolvers, where they do differ
from the internal resolver, are not installing any different
build‐dependencies than which the maintainer requested. The
variation lies in leaf packages; the packages the maintainer
wanted are always installed.


9. Next steps

Is resolving virtual dependencies bad? Well, we are
already resolving them anyway. Any indirect virtual depen‐
dencies (virtual dependencies of build dependencies) are
being satisfied by apt‐get using the current internal
resolver. Supporting them in sbuild merely makes this be‐
haviour consistent, and as the above analysis demonstrates,
most of the alternatives are not in the build dependencies
themselves, they are indirect.

Are alternative dependencies bad? Almost unequivocally
yes. The entire point of build dependencies is to specify
exactly the packages required for building; by allowing mul‐
tiple possibilities, the reproducibility and consistency of
builds is compromised. Almost every single existing use of
alternative dependencies is buggy. There are only a limited
number of legitimate uses for alternative dependencies,
examples of which include using different packages on dif‐
ferent architectures (e.g. linux vs. kfreebsd vs. hurd)
where consistency on a single architecture is still guaran‐
teed, or to permit easier backporting when the packages have
been renamed. Every example seen here, the Qt 3 and 4
alternative being the worst, was buggy. However, the hand‐
ful of packages misusing alternatives are a tiny minority.

Whether or not alternative dependencies should be
allowed in build dependencies is a long‐standing point of
contention. The question of whether they are allowed is
completely orthogonal to whether they are possible. The apt
and aptitude resolvers make the use of alternative build
dependencies possible, as a side effect of using a fully
functional resolver. This does not imply that they should
be used. We should not enforce an unwritten policy through
long‐standing defects in our tools; the restrictions should
be defined in Policy, and compliance with Policy validated
with tools such as lintian.

To be completely clear about this, the purpose of the
apt and aptitude resolvers is not to enable the use of
alternative build dependencies. This is just a side effect.
The purpose is to replace a long obsolete and buggy resolver
with one which works under all circumstances, and doesn’t
break on a multitude of corner cases, and with new additions
to the dependency syntax. It will mean new syntax will be
usable when support is added to apt or aptitude, rather than
waiting for years, because the internal resolver is mostly
unmaintainable. The main gain is removing a big source of
unnecessary buggy complexity and replacing it with something
simple, understandable, maintainable and vastly more power‐
ful.

Is it safe to switch to apt or aptitude as the default
resolver? Almost certainly. This exhaustive test
demonstrates that 99.34–99.35% of the existing archive
builds entirely unchanged. Of the 0.65–0.66% which built
with an altered installed package set, zero failed to build.
The differences are explained by the different ways apt and
aptitude compute the dependencies depending upon how they
are invoked, and are almost entirely benign. There are some
packages with currently buggy dependencies which should be
fixed irrespective of the resolver used. The apt and apti‐
tude build resolvers are largely equivalent, with only a
0.02% difference.

lintian should be able to check for misuse of alterna‐
tive and virtual dependencies in Build‐Depends and Build‐
Conflicts.

10. Work items

· Aptitude resolver must terminate build on install‐deps
failure. Not a serious bug, but it means the cause of
failure is reported correctly.

· Should the internal resolver delegate virtual depen‐
dency resolution to apt‐get (current release behaviour)
or revert to aborting all builds using virtual depen‐
dencies?

· apt and aptitude resolvers don’t print the parsed pack‐
age build dependencies, so it’s not possible to
directly check the installed package set matches what
was requested. Print the list as for internal.


--
.'`. 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.
 

Thread Tools




All times are GMT. The time now is 04:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org