Re: Multiarch file overlap summary and proposal
Russ Allbery <firstname.lastname@example.org> writes:
> Joey Hess <email@example.com> writes:
>> Anyway, my worry about the refcounting approach (or perhaps M-A: same in
>> general) is not the details of the implementation in dpkg, but the added
>> mental complexity of dpkg now being able to have multiple distinct
>> packages installed under the same name. I had a brief exposure to rpm,
>> which can install multiple versions of the same package, and that was
>> the main cause of much confusing behavior in rpm. While dpkg's invariant
>> that all co-installable package names be unique (and have unique files)
>> has certianly led to lots of ugly package names, it's kept the users'
>> and developers' mental models quite simple.
>> I worry that we have barely begun to scratch the surface of the added
>> complexity of losing this invariant.
> This does seem to be more M-A: same in general, to me, since whether we
> have file overlaps or not we still have multiple packages with the same
> name. Which will force changes in everything that deals with packages,
> like Puppet, to be able to specify packages with particular architectures.
> I definitely agree on the complexity this adds. But I don't think there's
> an alternative to that complexity without using something like --sysroot
> or mini-chroots, and I don't think those are satisfying solutions to the
> set of problems we're trying to solve.
pkg:arch will still be unique and the dpkg/apt output will use the
architecture where required for uniqueness. So I think that after some
getting used to it it will be clear enough again.