Re: A Radical Multi-Arch Counter-Proposal
Stephen Frost <sfrost@snowman.net> writes:
> * Anthony DeRobertis (asd@suespammers.org) wrote:
> > Proposal:
> > A. dpkg will be extended to support installing two packages with
> > the same name, but different ABIs, as previously proposed.
>
> Yeah, so, you've already killed it, sorry. Lots of assumptions in the
> system based on single-package single-name, not to mention much more
> complex for our users to have to deal with.
User should never have to deal with the difference. They only have to
select binaries to be installed, which would pick the best arch
available automatically.
User still just do "apt-get install foobar" or run tasksel or similar.
Developers might have to use "apt-get install libgtk-dev:i386", but
only on multiarch setups. If thats to complex for them they should not
install multiarch but stay with just one.
> > B. dpkg will be extended to support two packages with the same name
> > (as above) both owning the same file. It will only remove a file
> > from the filesystem when the last owning package is removed.
>
> Uhhh, and if the files are different between the two packages? What
> about different versions of the packages? I see below you're just going
> to 'error out', there's a small problem there though, that's probably
> going to be pretty often and that makes it not a reasonable thing to do.
There is only a very limited number of files that should conflict and
not be in their own package. In fact there is only one thing creating
conflicts and that is /usr/share/doc/<pkg>. Anything else you might
think about will have just the same conflicts without this proposal
(and the far more ugly package renaming or other hacks).
> Not to mention the added complexity to dpkg, bringing in lots of
> opportunity for bugs and making life that much more confusing for our
> users.
>
> Stephen
Looking at the 650 bugs of dpkg I don't think they need an
opportunity, they already have enough.
The complexity increase is minimal if you leave out the conflicting
files (which can and probably should be dealt with in another
manner). Changing dpkg and all affected tools will take some time but
there is enough time till sarge+1 to get this stable. And who knows
maybe till then dpkg v2.0 comes around.
For the users I think it will be far easier to have one simple rule
(:arch if at all needed) than the chaos that results from renaming.
Do you think users won't be confused if they suddenly see an apache
and apache64 package, perl-5.6 and perl64-5.6 package, ocaml and
ocaml64 package, and many more.
Everything that has any linking between packages need to be renamed
for amd64 and then both packages will show up in the frontends.
MfG
Goswin
Reply to: