[ 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 (firstname.lastname@example.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 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.
Description: This is a digitally signed message part