"Tshepang Lekhonkhobe" <[EMAIL PROTECTED]> writes:
> On 1/2/07, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote:
>> On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
>> > On Tue, Jan 02, 2007 at 04:28:59PM +0200, Tshepang Lekhonkhobe wrote:
>> > > On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
>> > > Why not have an extra /usr/share/doc/$source-name directory in case a
>> > > binary package of the same name doesn't exist or is not found to be
>> > > installed. This would be a problem when dependencies change, but on
>> > > package removal, /usr/share/doc/$source-name would be left alone if
>> > > there remains binary packages built from that source package.
>> >
>> > That's what $package-common packages are for. But just to hold the
>> > copyright and changelog that's an overkill because those packages would
>> > need some kind of garbage collection somehow and that i'm quite sure
>> > that it would use more mirror resources than the repeated changelogs.
>> >
>> > Well all in one it's not worth the effort, and has many drawbacks
>> > IMHO. I'd say that's a thing you may consider when you already need a
>> > $package-common for your packaging, but it's not necessarily a good
>> > idea.
>> >
>> > just to know what we are talking about, on my system:
>> >
>> > du /usr/share/doc/*/changelog.Debian.gz: 16M
>> > du /usr/share/doc/*/copyright: 15M
>> > du /usr/lib/iceweasel/firefox-bin: 15M
>> >
>> > so well, if it's not nothing, it's still quite small, and I can't
>> > imagine a system where 30M is an issue nowadays (well except PDA's or
>> > so, but here the whole /usr/share/doc is an issue at once anyway, like
>> > Don already explained it - on my system /usr/share/doc is 234M big).
>>
>> Pretty well-justified that this would be a useless effort. Along with
>> Don's mention that binary packages don't have to be the same version
>> it just shows that my proposal sucks.
>>
>> thanks
>
> By the way, this proposal was made because I browsed through
> /usr/share/doc/$package/changelog.Debian.gz to find that they were the
> same for different binary packages and expecting otherwise. I guess
> it's too much trouble doing separate changelogs for binary packages.
Two things to mention:
1) binary packages from the same source can be installed in different
versions. Those would have different changelogs. With seperate dirs
they do, with a $source-name dir they won't.
Having a -common file containing the changelog is probably only a good
idea when there is a strict versioned depends on it so the foo and
foo-common package always match.
2) multiarch has a problem with changelogs in library packages. It
must be possible to insall libc6:i386 and libc6:amd64. If both contain
/usr/share/doc/libc6/changelog then that gives a file conflict in
dpkg. Having the changelog in libc6-common beautifully solves this
problem and avoids having to special case this in dpkg.
Actually for multiarch I'm thinking of postfixing the doc dir with the
architecture (e.g. /usr/share/doc/libc_amd64) and have a link from
libc6 to the newest version of libc6_*. Or to the one last
installed. Alternatively the conflicting files could be postfixed with
the arch (e.g. changelog.gz_amd64) when there is a conflict.
The main problem is always cleanup on removal. Say libc6:i386 holds
/usr/share/doc/libc6/changelog.gz, libc6:amd64 holds
/usr/share/doc/libc6/changelog.gz_amd64. When libc6:i386 is removed
dpkg should cleanup properly and rename
/usr/share/doc/libc6/changelog.gz_amd64 to
/usr/share/doc/libc6/changelog.gz.
Better solutions are welcome.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
