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

Re: Multiarch file overlap summary and proposal



Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
> 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:*

Yes.

> * dpkg-repack pkg:arch will create a package with that literal name (or fail)

This is of course also a (new) bug.  There will be a lot of bugs like
this while we deploy multiarch.

> * dpkg-reconfigure probably can't be used with M-A same packages.
>   debconf probably generally needs porting to multiarch.

I think the non-arch-qualified nature of debconf question ids is
probably a feature rather than a bug.  These questions should be
arch-qualified by the package only if they need to be.

> [other examples]

Yes.

> Seems like we need a release where multiarch is classed as an
> experimental feature, which when enabled can break the system.

Certainly.  That's what wheezy will be.

>  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.

I think the fact that (package name, architecture) is still unique on
the system will be sufficient to make it possible to update all
existing software to deal with the new model.

> 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.

I don't think this is likely.

Ian.


Reply to: