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

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:*

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

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: