[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-cross multiarch transition

On Sat, 16 Jan 2010 11:06:43 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:

> Simon Richter (GyrosGeier) and I discussed this at length on irc prior
> to this mail and I think some ideas have been lost between irc and
> here.

I have access to the IRC log and used that as part of the plan.
> One of the main points was to NOT have to rely on external information
> that will be specific to a release (stable/testing/unstable) or just
> plain out-of-sync with the users system.

One of my main objectives was to ensure that this worked cleanly with a
Lenny installation and did not change current behaviour *unless*
multiarched packages are available.

There is no point causing pain to those users who do not have to deal
with multiarched packages.
> As mentioned in the mail dpkg-cross can not know if the package is
> ment for stable, testing or unstable. Further it also can't know if
> the user has different packages installed locally. The user might
> multiarchify libfoo and install that even though Debian still has the
> old one. He might have libfoo on hold because the multiarchified
> version in Debian has bugs. He might be mixing stable, testing and
> unstable. And on and on.
> GyrosGeier came up with the solution of keeping the libfoo-arm-cross
> as an empty dummy deb that depends on libfoo once libfoo is
> multiarchified and keeping the Depends on libfoo-arm-cross in reverse
> depends. 

Umm, I think there's some confusion there.

The current model is:

Non-multiarched libfoo:
Depends: libbar

-armel-cross of libfoo:
Depends: libbar-armel-cross

Multiarched libfoo:
Depends: libbar

-armel-cross of libfoo:
Depends: libbar

libfoo-armel-cross is installed as empty package so that reverse
dependencies of libfoo-armel-cross are retained.

The alternative, as I understand it, is that dpkg-cross suddenly
changes behaviour for all packages, multiarch or not, to have:

Depends: libbar, libbar-armel-cross

That is a big change in the behaviour and severely complicates using
dpkg-cross when targetting Lenny.

libfoo-ARCH-cross packages should not depend on libfoo UNTIL libfoo has
been multiarched.

If someone multiarches libfoo locally, add that package name to a file
in /etc/dpkg-cross/multiarch-cross.d/ (dpkg-cross will only update a
single file in that directory upon installation, any other file is for
the local admin to maintain.)

I don't see the need to support downgrades - Debian has never supported
downgrades. All transitions in Debian are one-way. If we try to make
them two-way, things will break that are outside the control of

> That way the reverse depends will work with the old libfoo
> and multiarchified libfoo package, with stable, testing, unstable or
> any mixture of them.

Why support mixing environments in the first place? It's never worked
before and moving to multiarch doesn't make it work for the future
either. One chroot, one target suite.

You can't have version 0.0.1-1 and version 0.0.2-1 of libfoo1 installed
at the same time, either native or cross. So if stable has 0.0.1-1 and
unstable has 0.0.2-1, you cannot mix those suites without using a
separate chroot.

> This also allows upgrading or downgrading, as far
> as the debian package supports it. So there is no one-way transition
> and no need to reinstall reverse depends.

Part of the work has been to ensure that cross-builds work in a clean
chroot without needing the duplication of having the amd64 and
armel-cross packages co-installed.

> So your problem goes all away if you use an empty
> /etc/dpkg-cross/multiarch-cross.d/ and empty /var/lib/apt-cross/. No
> more transition needed. The only pain is that a bunch of empty dummy
> packages will be kept installed as long as a reverse dependency is not
> multiarchified.

I don't see that it does - dpkg-cross cannot tell which packages to
process the new way and which to process in the old way. With current
dpkg-cross, we don't *need* the native version installed alongside the
-cross version.
The pain is that now libfoo-armel-cross depends on a non-multiarched
libfoo which depends on a whole chain of non-multiarched libraries,
requiring a complete duplication of the entire dependency chain in
amd64 and armel, merely to install an empty package.

That is not helpful if the setup in question *has* no
multiarch-compliant packages.

> For dpkg-cross (and apt-cross) there could be multiple configuration:
> 1) always use libfoo-arm-cross
>    - safe mode
>    - always works
>    - keeps more empty dummy debs installed than neccessary

What do you mean always use libfoo-arm-cross? Always add it to the
Depends? That forces the retention of the non-multiarched dependencies
as well - causing the -cross packages to cross-depend on the native
package set. We have tried (very hard) to avoid that before. It causes
IMMENSE pain when trying to upgrade the native (non-multiarched)
version of a package during a SONAME transition.

Imagine, in your setup, that libfoo goes from libfoo1 to libfoo2. If
libfoo is something like an X library (or a reverse dependency of an
X library) then it will have hundreds of reverse dependencies. Debian
will take great care to rebuild whichever packages need to cope with
the transition and libfoo2 should be installable. Once
libfoo1-armel-cross depends on libfoo1, everything breaks. apt-cross is
not sufficiently intelligent to be able to replace libfoo1-armel-cross
with libfoo2-armel-cross - it cannot work out which reverse
dependencies would need to be rebuilt. Therefore, the user is faced
with having to remove a huge chunk of the armel-cross packages merely
to be able to install libfoo2 for amd64. Then, once that is installed,
having to use apt-cross to re-install all the -cross dependencies that
apt has just removed.

That is NOT acceptable and neither dpkg-cross nor apt-cross have ANY
way of handling this conversion, short of removing hundreds of
packages and rebuilding them again. That is a huge amount of pain and
pointless churn.

-cross packages must NOT depend on non-multiarched native packages.

-cross packages should depend only on multiarched packages.

dpkg-cross is completely unable to tell the difference and needs an
external way of deciding. Your idea seems to be that dpkg-cross is told
to assume that everything is immediately multiarched as soon as the new
dpkg-cross is installed. That's a flag-day by another name.

> 2) use libfoo if libfoo:arm is already installed
>    - allows upgrades but not (easily) downgrades
>    - reinstalling/updating reverse depends drops libfoo-arm-cross
>      dependency

When processing libbar which depends on libfoo, we can't make this
decision. dpkg-cross would need to be ported to C and include 80% of
the code from /usr/bin/dpkg - I am not going to be the one to do that.
I'm guessing that you or Simon don't really want to do that either.
dpkg-cross knows nothing about the status of the installed packages,
it doesn't have any parser for that data - it relies on dpkg to do that.

This close to the end-of-life for dpkg-cross, there seems to be no
point adding that much new code.

> 3) use list provided by user / apt-cross
>    - user can mess up the list
>    - hard to consider default release, pinning, hold status, ... to
>      generate the list in apt-cross
>    - forces upgrades and doesn't allow downgrades
>    - breaks when sources are temporarily disabled

> Personally I think option 3, as described in your previous mail, is
> too fragile and the benefit of droping a few empty dummy debs is just
> not worth it. I have ~2000 debs installed. 100 additional empty dummy
> debs won't make a difference.

It pollutes the dependencies by causing the -cross packages to depend
on the native packages BEFORE those packages are multiarched.

Option 3 is necessarily fragile because the other options cause too
much pain upon a SONAME transition.

The multiarch transition is going to be fragile and painful for
dpkg-cross, there's no way around that.


Neil Williams

Attachment: pgpCOA9v66FlQ.pgp
Description: PGP signature

Reply to: