Re: Multiarch file overlap summary and proposal
Joey Hess <joeyh@debian.org> writes:
> Goswin von Brederlow wrote:
>> 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.
>
> Here are a few examples of the problems I worry about. I have not
> verified any of them, and they're clearly biased toward code I am
> familiar with, which suggests there are many other similar problems.
>
> * Puppet not only installs packages, it may remove them. A puppet config
> that does dpkg --purge foo will fail if multiarch is enabled, now
> it needs to find and remove foo:*
>
> * dpkg-repack pkg:arch will create a package with that literal name (or fail)
>
> * dpkg-reconfigure probably can't be used with M-A same packages.
> debconf probably generally needs porting to multiarch.
>
> * tasksel uses dpkg --query to work out if a task's dependencies are
> installed. In the event that a library is directly part of a task,
> this will fail when multiarch is enabled.
>
> * Every piece of documentation that gives commands lines manipulating
> library packages is potentially broken.
>
> Seems like we need a release where multiarch is classed as an
> experimental feature, which when enabled can break the system. But the
> sort of problems above are the easy to anticipate ones; my real worry is
> the unanticipated classes of problems. Especially if we find intractable
> problems or levels of complexity introduced by dropping the unique
> package name invariant.
>
> My nightmare scenario is that we release with multiarch, discover that
> it's a net negative for our users (proprietary software on amd64 aside,
> nearly all the benefits are to developers AFAICS), and are stuck with it.
The specs were initialy written in such a way that single arch systems
would not change, that multiarch packages would keep functioning with a
mono-arch apt/dpkg and I think this was preserved so far.
If all interface changes foolow that idea then worst case tools will not
work in a multiarch configuration but still work in a monoarch
configuration. So let multiarch be experimental and only for developers
and risk takers. That is already a huge number of people.
MfG
Goswin
Reply to: