Re: Temporary solution for changelog problem in binNMUs
Small side note on this interesting idea:
On Tue, May 14, 2013 at 09:59:31AM +0200, Raphael Hertzog wrote:
> The other points are more difficult to solve but would be useful in their
> own to avoid the problem of small packages considered too heavy due to
> their meta-data. It might be worth to think a bit about it. What about
> allowing us to define some package like this in debian/control:
>
> Package: foo
> Extends: bar
> Description: <summary>
>
> This new "Extends" field would imply that all meta-data (including other
> missing control fields) is shared with the bar package and at build-time
> it transparently gets a supplementary "Depends: bar (= <foo-version>)" but
> the .deb would not have any changelog/copyright.
Also think about the upstream changelog. Some packages consist of 90%
changelogs which also shared with multiple binaries (e.g. tkmib). Not
sure how those could be turned into meta data as well though. Sometimes
they are only available as html.
In any case a theme to deduplicate Debian changelogs inside dpkg would
already solve many reports generated by dedup.d.n (e.g. chromium). While
the benefit of deduplicating changelogs within a single source package
is very limited compared to the cost (maintenance of the symlinks), the
benefit of deduplicating inside dpkg should be well noticeable.
If interested, I can aid in collecting numbers to quantify this. The
dedup.d.n backing database should be well suited for this and I can
provide dumps as well. project-b should know about file sizes as well.
Helmut
Reply to: