Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Mon, Dec 5, 2011 at 09:55, Guillem Jover <guillem@debian.org> wrote:
> One of the issues with cross-grading is that the native architecture for
> the running dpkg can be different than the one for the newly unpacked
> dpkg programs which get invoked during the dpkg run. So any package name
> I/O that can have a different meaning depending on which architecture is
> native is not acceptable. Affected are also front-ends having an arch
> world view calling dpkg multiple times while cross-grading it in one of
> those. This dicards considering pkgname equivalent to pkgname:native,
> and to print just pkgname when it can be ambiguous (as in possibly
> having multiple Multi-Arch: same instances).
Do we really need to worry that much about cross-grades that we need
to change interfaces and even use a different one compared to other tools
working in the same context?
I mean, i don't think it is too much to ask for to understand that if i
change the arch for dpkg that his understanding of native changes, too.
The same is true for APT and all other front-ends, but it seems to be
reasonable to not expect users to fully qualify architectures for all
packages they enter just because libapt might be cross-graded…
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…
> So I changed the code in the pu/multiarch/master to only print the
> arch qualifier for all “M-A: same” packages, and not for foreign
> non-“M-A: same” ones. This makes the output deterministic and consistent
> regardless of the native architecture.
>
> And while it can be argued that this might break backward compatibility,
> that's only because Debian will be multiarch enabled, the package name
> output will only switch to be arch qualified on distributions that have
> had packages marked that way through the field. Others will not get
> affected. In addition the fact that almost all shared libraries will
> get arch qualified means we'll be able to detect and fix any
> script/program not prepared for multiarch pretty quickly, which we have
> to do anyway.
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…
> 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…
Also, for compatibility it would be great if for all packages even if it
is not needed an architecture is accepted, e.g. for the foreign M-A: foreign
packages a user might have installed accepting foobar and foobar:armel.
> For package name input, taking into account the output restrictions,
> pkgname cannot mean pkgname:native whenever that could be ambiguous
> (M-A: same). The only options are then to either consider it pkgname:*
> or to fail. I still think pkgname == pkgname:* makes way more sense as
> an interface, but failing would also be acceptable to me (as it can
> always be switched to pkgname:*).
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
Best regards
David Kalnischkies
P.S.: Thanks Raphael for the forward/reminder on deity. I intended to
send that way earlier, but forgot about it after writing it offline… sorry.
Reply to: