Re: Another multiarch decision
Aurelien Jarno <aurelien@aurel32.net> writes:
> On Fri, Jun 27, 2008 at 03:31:51PM +0200, Goswin von Brederlow wrote:
>> 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.
>
> I don't really agree with that. Looking at the bug reports, a lot of
> them are not used to /usr/share/doc/ so changing that a bit more won't
> help.
>
> Also I just hope that most of them won't have to learn for the syntax of
> libfoo/i386, that is to say apt will be able to automatically install
> the packages of another architecture if a package is only available
> let's say on i386 (e.g. java web plugin).
That is left for frontends to decide. I would guess so.
>> 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.
>
> It won't be that miniscule, a lot of packages already have data which
> can go into a -common package, like manpages for example, but that
> currently are in an arch package.
45M /usr/share/man
Miniscule.
And I don't expect many 'Multi-Arch: abi' packages to have
manpages. Libraries generally don't.
MfG
Goswin
Reply to: