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

Niko Tyni ntyni at debian.org
Tue Aug 25 21:55:11 UTC 2009


tag 536384 patch
thanks

On Wed, Aug 19, 2009 at 05:31:35PM +1000, Brendan O'Dea wrote:
> 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).

> 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?

I think we should, and at least apt-listchanges does. The reason for
the rebuild is often documented in the binNMU changelog entry, so it's
not all machine generated.

> >> 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.

> 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).

I don't quite see how having a separate package makes sharing
/usr/share easier. Could you elaborate a bit?

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

I'm very much in two minds about this, maybe leaning a bit on not changing
things. Is there something else we should take into account? Maybe an
ftp-master opinion about increasing the archive size?

I think keeping perl-modules as a transitional empty package is enough
to make sure upgrades don't break, so that shouldn't be a worry.

> > 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.

Fine by me.

I propose we

- add the attached patch (which removes the /usr/share/doc
  symlinks of both perl-doc and perl-modules) for 5.10.1-1 / experimental
- clone this bug for further consideration of the perl+perl-modules join

so we can get the RC part moving forward.

Is that OK with you?
-- 
Niko Tyni   ntyni at debian.org


More information about the Perl-maintainers mailing list