Re: Another multiarch decision
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).
> 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.
> 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
>
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: