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

Re: Multiarch file overlap summary and proposal



Russ Allbery <rra@debian.org> writes:

> Joey Hess <joeyh@debian.org> 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.

MfG
        Goswin


Reply to: