[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package-superseded-by-perl

Hi all,

I want to clarify that my request in #912682 is not backed by experience. I'm pretty new here and don't know yet much about Debian packaging nor about the Perl maintainer group's habits.

I understand the benefits of Gregor's position and certainly don't want that my request creates too much extra work.

Now that I know a little bit more about the context, I'm fine with the current state.

But, as the newcomer I was a few weeks ago, some information about this might have been helpful.

I'm ready to update the group's policy to add a note about that (I think I'm not too bad at documenting stuffs). But, I don't know where would be the best place:

* The Debian Perl group policy (https://perl-team.pages.debian.net/policy.html)?
* The Debian Perl policy (https://www.debian.org/doc/packaging-manuals/perl-policy/)
* Another (new?) FAQ page?
* Other?

Nor how to do it.

Also, I wonder if this kind of bugs shouldn't be marked with the "wontfix" tag (and, possibly also the "sid", "stretch-ignore", and "buster-ignore").  Would you mind if I do that?



On Sun, Jan 13, 2019 at 3:15 PM gregor herrmann <gregoa@debian.org> wrote:
On Sun, 13 Jan 2019 10:33:47 +0200, Niko Tyni wrote:

> According to lintian we have a dozen packages of dual life modules in
> sid that are 'useless' in the sense that the modules are also shipped
> in the Perl core with at least the same version.

Thanks for bringing this up.

> It seems clear to me that we don't want to ship any of these duplicated
> modules in buster,


> but before filing more bugs I wanted to discuss whether
> we want them removed from sid as well, as suggested by Dom in #915550
> and Cyrille in #912682.
> The tradeoff I can see is that removal from sid means a trip to NEW if we
> ever want/need to reintroduce them, but keeping them in sid indefinitely
> bloats the archive etc. In the case where the separate package is actually
> uninstallable (currently just libextutils-parsexs-perl), having it in sid
> is also a burden to other developers doing archive wide CI testing etc.

I'm a bit ambiguous; in cases which are broken in sid
(libextutils-parsexs-perl) just removing them makes sense of course.

In all other cases I consider the cost of keeping them minimal enough
to not jump through current or future hoops, at least if there are
signs of activity and a trace of needing newer versions.

> I think for my part I'm slightly inclined to having them all removed
> from sid, so any objections to that?

Well, let's say no strong objections :)

> In any case, I'd like to have libextutils-parsexs-perl removed as it's
> showing up on all kinds of automated test reports.


Maybe an additional aspect might be how actively maintained the
distributions are on the CPAN / when the last upload was / if they
tend to be required by other packages / … Let me try:

> libautodie-perl 2.29-2 with 2.29

2015; maintained in core now
only old dependencies

> libcpan-meta-perl 2.150010-2 with 2.150010

2016, hardly any acitivity in git since then
some non-ancient dependencies like
"perl (>= 5.23.0) | libcpan-meta-perl (>= 2.150005),"

> libcpan-meta-requirements-perl 2.140-1 with 2.140

2015, hardly any acitivity in git since then
some dependencies like
"perl (>= 5.23.0) | libcpan-meta-requirements-perl (>= 2.133)"

> libcpan-meta-yaml-perl 0.018-1 with 0.018

2015, no activity
one package with
"perl (>= 5.23.0) | libcpan-meta-yaml-perl (>= 0.016)"

> libextutils-cbuilder-perl 0.280230-1 with 0.280230

2017, some activity, but "Update from blead" so presumably maintained
in core
dependencies irrelevant

> libextutils-parsexs-perl 3.350000-1 with 3.390000

(known broken)

> libio-socket-ip-perl 0.39-1 with 0.39

Nov. 2017, no visible repo
quite a few dependencies, mostly for old versions, 2x
"perl (>= 5.21.4) | libio-socket-ip-perl (>= 0.32)"

> libmodule-load-conditional-perl 0.68-1 with 0.68

2016, no commits
hardly any dependencies, 1 package with
"libmodule-load-conditional-perl (>= 0.66) | perl (>= 5.25.4)"

> libmodule-metadata-perl 1.000033-1 with 1.000033

2016, but recent commits and a trial release in July 2018
a few dependencies, mostly old, one package with
"perl (>= 5.23.0) | libmodule-metadata-perl (>= 1.000027)"

> libpod-simple-perl 3.35-1 with 3.35

2016, no activity since then
a few dependencies, the newest
"perl (>= 5.23.5) | libpod-simple-perl"

> libsocket-perl 2.027-2+b1 with 2.027

January 2018, no visible repo
a few dependencies, the newest
"perl (>= 5.23.0) | libsocket-perl (>= 2.019)"

> libtest-harness-perl 3.42-1 with 3.42

February, March 2018
a few dependencies, the newest is
"perl (>= 5.21.8) | libtest-harness-perl (>= 3.35)"

/* The "one package" above is in most cases cpanminus which
 * originally bundled the recent versions at that time.

So from an activity and upstream maintenance point of view,
libio-socket-ip-perl (Paul), libsocket-perl (Paul), libtest-harness-perl
(Leon) (and maybe libmodule-metadata-perl) might be candidates for

>From a dependency point of view it seems that the demand for newer
versions of those modules has declined, presumably most authors were
happy with what's in perl core.

Now I'm not sure what my summary is.
Personally I'd probably keep libio-socket-ip-perl, libsocket-perl,
and libtest-harness-perl; but again, I won't protest if you want to
remove all :)

For the future (as we face the same question before each release)
maybe we can (at a sprint?) come up with some guidelines?
Like "no release in the last 2 years" or something?


 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: B.B. King and Eric Clapton

Reply to: