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 dpkg-cross. > 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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpCOA9v66FlQ.pgp
Description: PGP signature