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

arch-specific dependencies and M-A: foreign

Hi Multi-Archers!

Consider this situation:

Native Architecture: amd64
Foreign Architecture(s): i386

and these two packages:

Package: foo
Architecture: amd64
Depends: bar:i386

Package: bar
Architecture: amd64
Multi-Arch: foreign

Do you think 'foo' is installable? What if we change the architecture of
'bar' to 'i386' and let 'foo' depend on 'bar:amd64', does that change
anything? What if we let 'foo' depend on 'bar' instead?

I ran some tests and dpkg and APT¹ disagree quite fundamentally here. dpkg
declares 'foo' uninstallable in the first two cases and only the last
one as okay, while APT is willing to accept all three situations.

Now, imagine instead of 'bar' we had three other packages which provide
'bar'. Some of those providers are M-A:foreign, some not. What now?  And
to turn this up to eleven: Lets change 'Depends' to 'Conflicts' …

In other words my questions are: Is "bar:i386" referring to "bar:i386
only" or is it referring to "everything implementing bar:i386"?
And is therefore also "bar" the same as "bar:amd64" (, "bar:native" and
"bar:all") or not?

My personal opinion is (unsurprisingly perhaps) APT's interpretation as
the point of M-A: foreign is satisfying dependencies of another
architecture. If there really is a meaningful difference between
architectures a reverse-dependency could observe, perhaps bar should be
M-A: allowed instead…

Beside this, I think it also provides us with some interesting benefits
while changing a package from arch:all to arch:any (or v.v.) or
a package moves from M-A:none to M-A:foreign (or v.v.). It could also be
interesting if we ever get stuff like partial architectures…

These are all arguments made up after the fact through. The real reason
for APT doing it this way is that it comes natural out of the
implementation.  Doing it differently would be an enormous pain² so
I never even considered that another way of interpreting it might exist
until my nose got rubbed in it yesterday….

So, unable to find supporting evidence for either case in the few
specifications, I am appealing now to the high court of Multi-Arch.

Best regards

David Kalnischkies

¹ referring to apt-get here in particular, but anything using libapt is
² implementation-wise in libapt as it's trying to hide all of multiarch
by translating the problem to singlearch with heaps of explicitly
created implicit dependencies and (versioned) provides. Otherwise we
would have had to throw away at least half of the apt ecosystem…

Attachment: signature.asc
Description: Digital signature

Reply to: