Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

[Brendan O'Dea]

On Mon, Aug 17, 2009 at 7:01 AM, Niko Tyni<ntyni at debian.org> wrote:
>> There are ways around that, have the perl package provide a name which
>> maps to the debian version less NMUs (either by manually updating
>> debian/control, or an automated process which removes bin NMUs from
>> the version).
>
> As binNMUs get an extra changelog entry compared to their arch:all
> counterparts, all approaches that try to make them equivalent seem
> fundamentally broken to me. But maybe I'm just misunderstanding you.

I was suggesting:

  Package: perl
  Provides: perl-${debian-base:Version}

  Package: perl-modules
  Depends: perl-${debian-base:Version}

or something similar, and to have debian-base:Version set by
debian/rules to be the Debian version =~ s/\+b\d+$//

This would mean that arch-indep packages may have a changelog which
contains one or more binary NMU lines that technically do not apply,
but as these are machine generated metadata do we really care?

>> Another alternative, certainly the simplest, would be to remove
>> perl-modules entirely and have those arch-indep parts included in the
>> perl package. [...]
> I find this suggestion somewhat appealing, particularly as it would
> remove the dependency loop that people frequently complain about
> (#527917 / #502455) and simplify major version upgrades.
>
> The size of the packages is roughly
>              package size    installed-size
> perl              5M               15M
> perl-modules      3M               15M
>
> so with ~15 architectures, the join would take on the order of 50
> megabytes more mirror space per suite, altogether something like 200
> megabytes.  That does sound a bit much, but OTOH it's less than .1 %
> of the total archive size.

Note that while size in the archive was part of the original
motivation of splitting the arch-indep parts out, it also seemed to be
the correct thing to do in so far as making scenarios such as
described in the FHS easier to manage
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA).

Having said that, I'm inclined to believe that merging the two is
perhaps the best course.

> A quick count shows 116 packages in sid that have a versioned dependency
> (build- or otherwise) on perl-modules. Those would have to be fixed
> first unless we provided a transitional empty perl-modules package.

My inclination would be to have an empty package.

> In any case, the join wouldn't solve the issue this bug is about
> completely, as perl-doc also has an arch:all->arch:any symlink in
> /usr/share/doc. It therefore seems to me that a possible perl/perl-modules
> join is a separate matter and should not necessarily be coupled with
> this bug.

This similarly could be solved with the provides/dependency as described above.

> I think removing the symlinks with maintainer scripts and separating
> the /usr/share/doc entries is the best course of action here.

Sure.  I would still be inclined to keep the majority of the
documentation under /usr/share/doc/perl (as it is currently), and
merely have copies of changelog.Debian.gz, copyright and perhaps a
short README.Debian in /usr/share/doc/perl-doc.

If, OTOH you think that it would be clearer to split the docs across
perl-base, perl and perl-doc, I can take a look at what machinations
would be required to apply that on update.

--bod