[ FYI: I'm on both -devel and -amd64, no need to CC me. Though maybe
there is with how slow lists haven been going as of late... ]
On Fri, 2004-01-16 at 10:02, Stephen Frost wrote:
> * 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.
Well, I'm not sure how having packages with the same name makes things
more complicated for users. Front-ends can certainly display names like
"foo:i386" or, better, something like "foo (i386)." I think the
alternative is to add something like 4000[0] packages, and I'm pretty
sure that will be confusing for our users.
The other alternative, which I suppose would not be confusing, would be
to follow RedHat and Suse: Don't bother with multi-arch, just do a plain
old port. And several ports for mips. And for PowerPC 64. And so on. I
don't think that is a good plan.
As far as things assuming name uniqueness, yes, they'll have to change.
I did say it was a radical proposal :-) However, those things can use
names like package:arch.
>
> > 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?
Then the two packages can't be installed at the same time. They should
not be 'Multi-Arch: yes'.
> What
> about different versions of the packages?
I covered that. Either we'd require the same version (which isn't that
bad for especially for stable, since the testing scripts already do) or
when a coalesced file is changed, you need to declare a conflict with
the old version on all architectures.
> 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.
Basically, if coalescing files fails, pretend the dpkg-coalesce features
do not exist and proceed. So it'll error out with the same errors it
would today.
And, just like today, that would be a RC bug. Nothing there actually
changes, except that we can usually allow two or more architectures of
-dev packages to be installed, without creating a single new package.
> 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
I have not actually tried implementing this, so I can't say for sure how
complicated it is. Certainly, it requires more dpkg changes than
renaming. However, when I wrote the proposal, I was careful that all I
was asking for was reference counting. Conceptually, it seems relatively
simple. I'm sure, of course, the devil is in the details.
But this is something that would be done for sarge+1 at best. We'd have
plenty of time to work out bugs.
FOOTNOTES:
1. As for 4000 packages, if we renamed and split to solve all
problems, there are 1135 dev packages in my available file, most
of which would need documentation, header files, etc. split into
a arch-all -common. There are 3153 lib* packages minus 879
lib*-dev packages (already counted) or 2274 libraries, many of
which would have to be packaged as libfoo and lib64foo. In
addition, those need to have documentation and other
arch-independent data split out to a -common. I think somewhere
around 4000 packages for a full 64-bit port using renaming and
splitting is a reasonable estimate.
Attachment:
signature.asc
Description: This is a digitally signed message part