Re: Another multiarch decision
Aurelien Jarno <aurelien@aurel32.net> writes:
> On Thu, Jun 26, 2008 at 01:32:47AM +0200, Goswin von Brederlow wrote:
>> Hi,
>>
>> I cleaned up some more of the old multiarch patches and hit another
>> spot where a decision must be made:
>>
>> ----------------------------------------------------------------------
>> Unpacking libhello/i386 (from .../libhello/libhello_1.0_i386.deb) ...
>> dpkg: error processing /home/mrvn/src/libhello/libhello_1.0_i386.deb (--install):
>> trying to overwrite `/usr/share/doc/libhello/changelog.gz', which is also in package libhello/amd64
>> ----------------------------------------------------------------------
>>
>> Every package must have a changelog and copyright and many also have a
>> Readme and NEWS file. Those and any other files in doc will collide
>> for multiarch.
>>
>> Dpkg could rename the files for the non native architecture by
>> prefixing them with the architecture, e.g.
>> /usr/share/doc/libhello/i386_changelog.gz
>> or
>> /usr/share/doc/libhello/i386/changelog.gz
>
> I don't really like this idea, this will most probably confuse the user,
> while also probably duplicating data.
They get used to it. They already have to learn the apt and dpkg
syntax of libfoo/i386 and will see that syntax in the dpkg output when
installing packages. I have faith in the ability of our users to learn.
An if the duplicating the doc files is amounting to anything then a
-common package would be called for. This would be truely just for
packages where a -common package is miniscule and therefore just
bloat.
On my server 903 out of 1298 packages have a /usr/share/doc below
100k, 639 below 50k, 402 below 30k. All including filesystem overhead
for 4k blocks.
> At some point it has been decided to provide a -common package for every
> package converted to multiarch, containing changelog, README, NEWS, and
> probably more thinks like man pages, info pages, etc.
>
> Then multiarch package could simply add a link from
> /usr/share/doc/package to /usr/share/doc/package-common, and we should
> change dpkg to allow a symlink to be overrided by another if both point
> to the same location.
>
> What do you think?
The only problem here is one of reference counting. dpkg would have to
know when the last package with the symlink is removed. Dpkg already
handles that for directories. If nothing else then packages could just
create the symlink in presinst if missing and contain an empty
directory.
So technically that is a minor problem. But as said before that would
create a lot of miniscule packages.
MfG
Goswin
Reply to: