Re: Multiarch file overlap summary and proposal
On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote:
> I agree that it's asymmetric. apt-get install libfoo means libfoo:native,
> but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all
> things being equal. But I think this may be one place where asymmetric is
> still the right thing to do; I would argue that it means you're
> implementing the most common operation in both cases. apt-get install
> libfoo generally means "give me a native libfoo" since non-native libfoo
> is going to be an unusual case, and apt-get remove libfoo generally means
> "I have no more interest in libfoo, make it go away." I think that people
> who want to get rid of one architecture of libfoo but keep the other are
> already going to be thinking about architectures, and it's natural to ask
> them to qualify their request.
>
> If removing the non-native architecture has cascading effects, apt is
> obviously going to warn them about that already and they'll realize what's
> going on.
This was already contemplated at least as part of one of the threads David
referenced:
<http://lists.debian.org/debian-dpkg/2011/12/msg00068.html>
> David Kalnischkies <kalnischkies@gmail.com> writes:
> > (Note though that e.g. APT is not able to handle installed architectures
> > as an 'attribute'. It not only has to handle them as 'different'
> > packages (and more specific different versions) to keep
> > backward-compatibility, also different dependencies on different
> > architectures would make it pretty messy in practice. But double-think
> > is a requirement for APT development anyway. ;) )
>
> Yes, definitely the internals of our package management software can't
> fully compress the packages together; at the least, the dependencies are
> going to be different between architectures and have to be stored
> separately. [...]
> But I think what we should be telling the *user*, regardless of our
> internals, is "don't think of libfoo:i386 and libfoo:amd64 as two separate
> packages that you can maintain independently; think of libfoo as being
> installed for one or more architectures."
The thing is, in practice they cannot share much at all, because even
if they might end up being at the same version, they need to go
through different versions inbetween. For dpkg, only the package name
and the reverse dependencies are shared, assuming any other field is
equal will only come down to lost metadata.
And while I have initially actually been working with the mental model
of pkgname with multiple arch instances as an internal detail, the fact
is that this abstraction just leaks everywhere, and trying to shield
the users and maintainers from that reality will only cause pain. It's
just a nice illusion coming from the fact that those packages share the
package name. But considering pkgname == pkgname:* means for example that
all query commands have to output information for multiple instances, so
packages/scripts/etc have to be adapted anyway to handle those, and
while I don't consider that a problem, just another side of the changes
needed for multiarch, it shows how the interface can only possibly be
transparent on one side of the interface, if at all.
Finally, the thing is, those packages are really independent, they just
happen to share a name and a common source ancestor, but they can contain
different files per arch instance, different metadata, even different
maintainer script behaviour per arch, etc. And only packages from the
same arch can depend on them.
> > Mhh. The current spec just forbids binNMU for M-A:same packages -
> > the 'sync' happens on the exact binary version.
> > Somewhere else in this multiarch-discussion was hinted that we could
> > sync on the version in (optional) Source tag instead to allow binNMU.
>
> I think that the best long-term way to handle binNMUs may be to move the
> build number into a different piece of package metadata from the version.
> So a binNMU of a package with version 1.4-1 would still have version 1.4-1
> but would have a build number of 2 instead of 1. I think this would be
> way cleaner in the long run, and not just for multiarch.
That means then we cannot state a relationship based on the binNMU
version. And while that might be desirable most of the times, it makes
it impossible when it might be desirable. Without considering this
deeper, it also reminds me of when Revision was a distinct field. In
any case how to handle binNMUs is something that should be carefully
considered and not be rushed out now, just because suddently they cannot
be used...
regards,
guillem
Reply to: