On Fri, Jun 27, 2008 at 03:31:51PM +0200, Goswin von Brederlow wrote: > Aurelien Jarno <[EMAIL PROTECTED]> 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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
