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

Re: dpkg-cross multiarch transition


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

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.

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. That way the reverse depends will work with the old libfoo
and multiarchified libfoo package, with stable, testing, unstable or
any mixture of them. 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.

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

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

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

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.


Reply to: