Re: A Radical Multi-Arch Counter-Proposal
Anthony DeRobertis <asd@suespammers.org> writes:
> On Jan 16, 2004, at 07:12, Goswin von Brederlow wrote:
>
> > Anthony DeRobertis <asd@suespammers.org> writes:
> >
> >> 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.
> >
> > Required for shared conffiles at the very least.
>
> Truthfully, I'm worried about shared configuration files. That mess
> seems hairy.
Why, the dpkg keeps "file: package1, package2, package3,...". Install
adds a package, purge removes one. If all packages are gone the file
is purged.
Overwrites of conffiles are already asking the user so there is no
problem there.
Also there isn't an example of this occuring yet. When it does we can
see how it goes, till then I will ignore this. I won#t even add shared
files support, dpkg will just refuse to overwrite another packages
file.
> >> C. dpkg will be extended so that if both a:ABI1 is installed and
> >> has "Multi-Arch: yes" set, and an install of a:ABI2 is
> >
> > Mips has 3 abis but only 2 archs. An "ABI: <abi>" line would imply
> > "Multi-Arch: yes", no such line "Multi-Arch: no".
>
> I think I'll rename this line to 'Coalesce: no' (to prohibit it) or
> something like that.
We already have the "ABI: ..." line patched into and a simple bool
won't do the same job. Better stick with our "ABI: ...".
> > Care must be taken on upgrades. When a file changes thats shared both
> > old packages can match, both new packages match but extracting just
> > one would conflict.
>
> Well, since we're working off the md5sums file, this is fairly easy to
> check before doing any unpacking. If you find it won't work, then tell
> the user the two packages he has tried to install conflict, and error
> out. If it does work, mark the packages half-unpacked and start
> unpacking.
>
>
> Of course, for values of "fairly easy" ranging from "untrained monkeys
> to do this" to "with this much work, could of made the dang thing
> sentient." I guess that means I've volunteered to find out....
Ignoring this for now till some solution is found for it. I will only
handle the /usr/share/doc/<pkg> conflicts.
> >> 2. if a:ABI2 has "Multi-Arch: no" set, refuse to proceed.
> >> 3. if a:ABI2 does NOT have "Multi-Arch:" set at all,
> >> attempt to install as normal without co-ownership.
> >
> > If a:ABI2 has no Multi-Arch set it should provide for all abis, that
> > mean it includes the functionality of a:ABI1 and should cnflict.
>
> Naming that 'Multi-Arch' in my original proposal was not a good
> idea. Maybe the ABI tag could be used for this (or isn't it
> already?). If I remember correctly:
>
>
> ABI: strict # provides for this ABI only
> # otherwise, provides for all compatible ABIs
No, ABI: ia32, amd64, mips, n32, n64, ....., ABI: <any> in the source
will be replaced by the current ABI.
A simple bool didn't look good enough for mips.
> If that's correct, those terms seem a little confusing --- why not
> list the ABI names it provides for, or 'all'? I think that might even
> make bootstrap easier, by just assuming a package that doesn't have an
> ABI line is traditional ABI of that architecture. So all the i386
> packages would assume ABI: i386.
32bit intel has ia32 as abi but yes, we saw that too.
> I think that 'can be installed along with other packages of the same
> name' and 'supports which ABIs' are different, and should use
> different fields.
>
>
> >
> > I don't think we can make the old packages (without Multi-Arch set) to
> > coexist with new multi-arch packages of the same package. It will
> > result in a conflict in 99% of all cases and dpkg should not even try
> > to install.
>
> I bet I can get most lib packages to work without trouble. That's what
> I'm hoping, at least. Probably even lib-dev ones as well.
>
>
> >
> >> D. dpkg will assume a means a:DEFAULT_ABI, which is the
> >> default ABI
>
> >> on the machine. a:* means "a of all ABIs"[1] (used in, e.g.,
> >> conflicts). a:ABI of course means that particular ABI.
> >
> > a means any ABI unless a only provides one ABI, than it mans matching
> > ABI and arch.
>
> I think we're saying essentially the same thing.
>
> If a provides all ABIs, then (to me) a clearly satisfies a Depends: on
> a:foo or a:bar or a:whatever.
No, a "Depends: a" would be satisfied. "Depends: a:foo" is for cases
when architecture foo is required for some reason that isn't covered
by the "ABI: ..." mechanism.
The ABI (of the lib) is checked in reverse against the "Architecture:
..." of the package (the binary) that Depends on it.
> >> E. Either dpkg must require a:* to all be the same version, or
> >> versions of a which change a common file must
> >> Conflicts: a:* << VERSION
> >
> > I can live with enforcing the same version. The other seems to much
> > work. You can hardly get around changing a header file in a -dev
> > package with every release. Everything would end up with a Conflicts
> > line just in case.
>
> I'll go with same version, then. We already require same version for a
> package to propagate to testing, anyway.
>
>
> >
> >> RATIONALE:
> >> * This will handle /usr/share/doc. We won't need any of the
> >> previously-proposed special behavior for
> >> /usr/share/doc/copyright.
> >
> > Shared files make upgrades complicated and fragile.
>
> I think otherwise; the only way to find out is to try. Which, by
> proposing, I suppose I have volunteered myself for.
Ok, you try with, I without and lets see what works best.
If it works with shared files a lot of split packages can probably be
avoided till they break on an upgrade.
> > Renaming the files
> > in doc to not be shared (either in the package or by dpkg) is
> > easier. But either way would work.
>
> Well, renaming all those files, splitting packages, etc. might be
> doable for sarge+1. I think it's quite an uphill battle (especially
> splitting that many packages). That requires touching a lot of
> packages. We could probably have a stable amd64 in three years, when
> sarge+1 releases.
>
> I'm hoping to be able to do it with minimal changes to sarge, so we
> could at least have an unofficial stable add-on to sarge in a year or
> so.
Yeah, providing full compatibility to sarge i386 would be nice but it
might not be fully possible.
> >> * This will allow most -dev packages to be multi-arched without
> >> splitting. This proposal creates no new packages.
> >
> > Unless the header files differ which many have claimed they will. But
> > dpkg would catch that gracefully.
>
> Yes, that's correct. I hope most dev packages can have their header
> files coalesced. But for the few that can't, hopefully having them
> conflict (or just being Coalesce: no) will be no big deal.
>
> >
> > With shared files the first lib installed provides the file, every
> > other abi getting installed or upgrades can show the dpkg "replace
> > conffile" dialog and the last lib purged would remove the conffile.
> >
> > Where is the problem there?
>
> On amd64, we'd be asking about replacing each conffile twice. On mips,
> apparently three times.
Thats the price for biarch/treearch. But I realy don't thing its
happening at all. Libs should not have conffiles.
> Technically, there is no problem. Practically, the lynch mob disagrees.
>
> >
> >> FOOTNOTES:
> >> 1. packages with Multi-Arch: yes must have an md5sums file.
> >
> > Generate md5sum in dpkg on the fly or just compare files.
>
> That requires unpacking first. An md5sum file compare is MUCH quicker,
> especially since that is part of the control archive.
You have to fetch and unpack the deb to get the md5sum file. The
difference between ar and gzip | md5sum is minimal for amd64.
MfG
Goswin
Reply to: