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

Re: arch-specific dependencies and M-A: foreign

On Fri, Apr 17, 2015 at 03:39:14PM +0200, Johannes Schauer wrote:
> > And is therefore also "bar" the same as "bar:amd64"
> no because different packages might provide "bar" and "bar:amd64". So even on
> amd64 this dependency might be resolved differently.

huh? Can you give an example?

My point of view here is that there isn't a difference between reading
"bar" and "bar:amd64" while parsing the dependencies of an amd64
package. As long as you don't give the ":amd64" a 'special' meaning of
course, which was the previous question.

> > (, "bar:native" and "bar:all"
> Is there a point in allowing to explicitly depend on a package of
> Architecture:all? Does this work with apt?

(Slightly embarrassed) Yes, but not as a feature, but as a "I haven't
taken explicit measures to prevent it". Neither is legal in
dependencies, native is legal in build-dependencies through.

That was meant as a reminder that amd64 is the native architecture in
this example and that architecture all is mapped to the native
architecture as well. Not as a valid specifier showcase, sorry…

> >) or not?
> dose3 agrees with apt here and is able to install "foo" in all three of your
> scenarios.
> This is because as far as dose3 is concerned, the dependency bar:i386 is
> satisfied by every provider of bar:i386. This can be either a package bar which
> is M-A:foreign and (in the future, after a bug [1] is fixed) also a package
> "blub" which Provides: bar:i386.

What about a package blub2:i386 which Provides: bar ? Isn't that
providing bar:i386 as well, because that is what bar stands for… ?
On the other hand blub2:amd64 which 'Provides: bar' isn't providing
bar:i386 (but bar:amd64), which was the topic of a previous mail [0]
from me to the list which while not generating a response, at least
dpkg seems to agree with me now on that one (now, future unknown, the
associated bugs are still open in dpkg and apt).

> > 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…
> Yes, if bar:amd64 would not also really provide bar:i386, then it should not be
> M-A:foreign.

The 'problem' spawning these questions is debugsymbol packages which do
depend on the package they provide debugsymbols for. Installing
debugsymbols for the wrong architecture isn't dangerous, but it is also
quite useless and its quite clear that a M-A:foreign doesn't apply

I guess instead of worrying about this usecase too much, we might be
better of not using a depends here at all. Potentially we are way better
of with 'foo-dbg enhances libfoo0, foo' and a 'apt-get debugsymbols foo'
grabbing -dbg packages enhancing foo (and potentially optionally the
same for its dependencies. Finding a good cut-off point might be hard
through… mhhh…) similar to how 'apt-get source foo' grabs the source for
the package foo. (in any case, not really the topic of this thread,
will move that where it belongs 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
> There is no M-A:none, it's M-A:no

Damn. Always the same mistake. (Hey brain, you can even save two
keystrokes here, do you realize that…)

> > 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….
> When I tested dose3's multiarch implementation I only tested it against apt
> because apt has the handy --simulate option. I do not know how to do similar
> tests with dpkg without needing superuser privileges. Is there a way?
> How did you compare apt and dpkg's behaviour in this case in practice?

Discussed off-list as its slightly off-topic here.

But for completeness in short: APT has a battery of shellscripts we
dubbed integration tests, which can among other things build packages
and (try to) install them via apt with dpkg as non-root in a temp

Best regards

David Kalnischkies

[0] https://lists.alioth.debian.org/pipermail/multiarch-devel/2014-November/000098.html

Attachment: signature.asc
Description: Digital signature

Reply to: