Hi,
first let me apologize to Norbert that my original email was unclear: it
is indeed true, as Raphael notes, that dpkg-deb (or whatever) is NOT
changing the order of individual packages within an OR'ed set, only of
the packages (or OR'ed sets of packages) separated by commas.
Raphael Hertzog wrote:
> On Thu, 21 Feb 2008, Kevin B. McCarty wrote:
>> I've just noticed that packages I've built recently have had the list of
>> Depends reorganized into ASCIIbetical order in the generated binary
>> .debs. I guess this was the next logical step after having dpkg-dev
>> re-order Build-Depends internally (as was discussed in #457151).
>
> There's no "next logical steps", it was done at the same time.
Sorry, I hadn't noticed the reorganization of the Depends in the actual
.debs until just yesterday, so I thought it might have happened later.
My mistake!
> I can understand it might change the list of packages pulled, but both set
> are supposed to work since that what dependencies are expressing. If you
> have additional restrictions, you'll have to express them more explicitely
> instead of relying on the internal ordering that apt-get/aptitude uses to
> parse the Depends field.
The problem with this is that dpkg/APT don't support combining multiple
packages into one alternative. So if A and B together provide the same
features as C, one can't just Depend: (A + B) | C, one needs to Depend:
A | C, B | C. Sometimes the order can be tricky to get right for all
cases. If the two groups separated by the comma are not in the right
order, in some cases (depending on what the user initially had
installed), the dependency can end up satisfied but with extraneous
additional packages also installed.
I guess this is a good place in the thread to give my examples (below).
It's also possible that more pathological problems could come up which I
haven't thought of.
> The problem with "unexpected changes" is that they are "unexpected"
> and it's thus difficult to give fore-warning. I would have gladly
> communicated more if I had somehow expected those problems. :-)
ACK, of course :-)
> That said this new behaviour is not particulary new. It's been in unstable
> since the 19th november 2007. And we haven't seen major breakage in the
> mean time.
OK (although I disagree that #457151 was not major breakage), but it's
possible that there are now more subtle dependency issues that may not
be detected for a while, just because either (a) no one had the right
combination of packages installed to trigger them, or (b) someone who
did didn't think it worth the trouble to file a bug, or didn't have the
knowledge to figure out what went wrong.
Anyway, my examples follow (warning, long & complicated) --
Example 1 (hypothetical).
As discussed at
http://lists.debian.org/debian-devel/2008/01/msg00815.html
http://lists.debian.org/debian-devel/2008/01/msg00817.html ,
consider a "gnome" meta-package (hypothetically, not the existing one!)
that wants to depend on an office suite, preferably gnome-office, but if
the user already has openoffice.org installed, then the GNOME bindings
for that would be OK, too. (Note that for good reasons irrelevant to
the example, openoffice.org-gnome does NOT depend on openoffice.org,
only on openoffice.org-core, which does not contain any user-callable
executables.) Relying on the fact that apt-get and aptitude currently
parse dependencies greedily in the order in which they appear, these
dependencies can be given as:
gnome-office | openoffice.org, openoffice.org-gnome | gnome-office
That is: if the user has gnome-office already and runs "apt-get install
gnome", nothing extra is pulled in because both dependencies are
satisfied. If the user has openoffice.org already, the second OR'ed
dependency pulls in openoffice.org-gnome (without pulling in
gnome-office). If the user has neither, she ends up with only gnome-office.
Now suppose that openoffice.org (and OOo-gnome) were named "cooloffice"
instead. The re-ordering of dependencies ASCIIbetically would now give:
cooloffice-gnome | gnome-office, gnome-office | cooloffice.
For the user with either gnome-office or cooloffice already installed,
nothing changes from above. But for the user starting with neither
installed, "apt-get install gnome" will now install cooloffice-gnome AND
gnome-office, so there is now a useless cooloffice-gnome package
installed (as well as its dependencies cooloffice-core and
cooloffice-common, totalling 145 MB) without the cooloffice package (or
even any of cooloffice-writer, etc.) that would make it useful.
Example 2 (historical).
Here I'll discuss the situation with BLAS and LAPACK packages prior to
the beginning of the g77 -> gfortran transition. (I may not get
everything exactly correct, but this is the gist of things.)
Two libdevel packages provided the symlink liblapack.so (lapack3-dev and
atlas3-base-dev), and two packages provided libblas.so (refblas3-dev and
atlas3-base-dev). The corresponding runtime library packages are named
lapack3, refblas3, and atlas3-base. Note that liblapack.so.3 (both
versions) requires libblas.so.3; but liblapack.so.3 from lapack3 can use
either version of libblas, while liblapack.so.3 from atlas3-base needs
the libblas.so.3 from atlas3-base-dev.
Two different versions of each library are provided because lapack3 and
refblas3 (and -dev) are the "reference" versions, while atlas3-base (and
-dev) ships optimized versions that may provide much faster versions of
the same routines.
In order for runtime and libdevel packages to be installed in parallel,
the maintainer of all three libraries chose to put the atlas3 versions
of lib{blas,lapack}.so{,.3} in /usr/lib/atlas and to add this directory
in /etc/ld.so.conf in the atlas3-base postinst, to make the (optimized)
atlas versions be the preferred runtime libraries. However, there is no
similar config file that could force the compiler and linker to look for
lib{blas,lapack}.so in /usr/lib/atlas by default.
Therefore, someone maintaining a libdevel package that needs
liblapack.so (such as my own libmathlib2-dev) will want to depend by
preference on lapack3-dev. (If only atlas3-base-dev is installed, users
of libmathlib2-dev will need to remember to add -L/usr/lib/atlas every
time they invoke the linker.)
So libmathlib2-dev might have "Depends: lapack3-dev | atlas3-base-dev".
Here there is another wrinkle: lapack3-dev depends on the runtime
package lapack3. Since users would generally prefer to have the
optimized version of libblas.so.3, the shlibs file of both refblas3 and
atlas3-base contains "atlas3-base | refblas3 | libblas.so.3" (the
virtual package libblas.so.3 is unimportant to this example). Thus the
Depends of lapack3 gives first preference to atlas3-base.
So in order to prevent lapack3-dev from indirectly pulling in
atlas3-base, one instead needs to have libmathlib2-dev have Depends:
refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev. Thus, if
one did "apt-get install libmathlib2-dev" while having no trace of any
version of BLAS or LAPACK already on the system, then the following
packages end up pulled in: refblas3-dev, lapack3-dev, and their runtime
libraries, but with no atlas.
If the dependencies of libmathlib2-dev had been re-ordered
ASCIIbetically at the time, to "lapack3-dev | atlas3-base-dev,
refblas3-dev | atlas3-base-dev", there would have been no way to prevent
the installation of atlas3-base indirectly via lapack3. (Short of a
Conflicts, which would certainly be overkill and might also confuse
APT's dependency resolution; or else a special plea to the maintainer of
ATLAS/BLAS/LAPACK to change his scheme, of course.) So an additional 18
MB of files (atlas3-base is a fairly big package) would end up installed
on the user's system, completely unnecessary for the purpose of
development with libmathlib2-dev.
Fortunately, with the gfortran transition, the libdevel packages have
been renamed to libblas-dev, liblapack-dev and libatlas-base-dev; thus
the rearrangement by ASCIIbetical order no longer presents a problem to
the solution described above.
Again, it's conceivable there could be other types of dependency
problems introduced, more problematic than getting unneeded packages
installed to waste disk space, that I haven't thought of.
best regards,
--
Kevin B. McCarty <kmccarty@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature