On Mon, 12 Dec 2011, David Kalnischkies wrote: > In the end, we properly need a specialized tool for cross grades anyway: > Changing the architecture of any package basically requires the > removal of this package before it can be installed for the new architecture: > I e.g. can't think of a good way for APT to instruct dpkg to > remove itself and install itself again in a different architecture…
dpkg supports the cross-grade, you can tell it to install a foreign package when a native one is already installed. So the goal is to allow the user to cross-grade his system with a "dpkg -i dpkg_1.16.2_<foreignarch>.deb" (modulo the need to pre-install the predependencies). > You talk only about output, but the title is "I/O" and i think it's unlikely > that dpkg has a different understanding of pkgname in output vs input, > so, you want to tell us that from now on we need to say (native=amd64): > dpkg --configure libc6:amd64 instead of > dpkg --configure libc6 , right? > > If that's really meant, i am very worried how release upgrades should > work, given that squeeze tools obviously don't know about this need… This proves that we can't make dpkg fail when it gets an unqualified package name in input. So in the alternatives that guillem proposed we have to pick "pkgname = pkgname:*" so that things keep working during upgrade when an old APT drives a new dpkg and that some M-A libraries are already installed. > > One option though if we'd want to preserve output compatibility could be > > to only allow co-installability and as such the need to disambiguate > > “M-A: same” instances only when a foreign architecture has been configured. > > Not allowing foreign architectures before they are configured would be > preferable, given that front-ends will have a hard time to know which > architectures they can expect -- beside that i wouldn't understand the > difference between: > a) foreign architecture configured and > b) foreign architecture not-configured > given that dpkg would seem to accept a) and b) then without a visible > difference, so why configuring at all… Foreign architectures packages are already forbidden by default (unless --force-architecture is in use). I don't know what Guillem was thinking about, maybe dropping the possibility to override the error. > I think Raphael started a discussion on the interface at the beginning of > the year in which it was discussed. I am offline now but i remember to > have typed a long answer and this one is going to be become long already, > so i am not going to repeat it here, just let me reiterate that > a) it feels strange to have different interfaces in the same context > b) requiring different inputs based on the M-A state asks for confusion > c) breaking release upgrades should be avoided My mail: http://lists.debian.org/debian-dpkg/2011/01/msg00046.html You mail was here: http://lists.debian.org/debian-dpkg/2011/02/msg00000.html Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212133736.gc29...@rivendell.home.ouaza.com
