Hi,

while looking for potential removal candidates, I somewhat randomly
stumbled upon libembperl-perl, whose current version in the archive is 2.5.0-15. Yes, -15, because it looks like upstream became inactive in
2014, and since then, members of our team adapted upstream code for
every change in the surrounding ecosystem:

- perl 5.20
- perl 5.22
- Apache 2.4.0
- CGI.pm >= 4.04
- PERL_USE_UNSAFE_INC being disabled by default in perl 5.26
- perl 5.28
- Apache 2.4.40
- {xml2,xslt}-config going away ⇒ switch to pkg-config
- current GCC (-Wmisleading-indentation)

Most of these patches were forwarded upstream, yielding no
reaction there.

So, let's face it: we've de facto been maintaining the upstream code
base since 6 years. I expect that if we keep this package in Debian,
we'll have to keep doing this on a regular basis.

Is this what we want?

Personally, I'm concerned by this situation for 2 reasons:

- This package is security sensitive: it's a "system for building
dynamic websites with Perl". I suppose some of these websites
are exposed publicly on Internet (<shudder>).

For example, a security issue (#731996, infoleak trivially
triggered remotely) was reported to us + upstream in 2014,
and not addressed yet.

More generally, sloccount tells me that half of the code base is
written in C. I don't think we're doing a great service to our
users by giving them the means to build websites using a framework
written in a memory-unsafe language.

- Is it the best use of our limited resources to maintain a de facto
fork of this unmaintained, and not very popular anymore, upstream
code base?

I see that popcon has been steadily decreasing since 2012;
currently, inst = 39.

I propose we do this:

1. Remove it from testing, in order to:

- Send a strong signal to Debian users who still rely on this
module, by *not* including it in Bullseye. Hopefully the few
remaining users will notice and migrate to something else, or
decide they care enough about the status quo to adopt this
module upstream.

- Decrease the urgency of future problems in this module: e.g.
they won't be blocking perl-5.xy upgrades and migrations anymore.

2. Keep it in sid until next time it badly breaks.

Depending on when this happens, on whether someone else than us
paid attention and took over upstream maintenance, and on the
feedback we got from step (1), then we can reconsider our options.

I certainly wouldn't mind removing it from sid now, but I know I don't represent the current consensus on our team wrt. trigger-happiness for
removing packages, hence this more iterative proposal :)

Thoughts?

Cheers!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Thanks for looking into this!

On 21/08/2020 10:31, intrigeri wrote:

I propose we do this:

1. Remove it from testing, in order to:

- Send a strong signal to Debian users who still rely on this
module, by *not* including it in Bullseye. Hopefully the few
remaining users will notice and migrate to something else, or
decide they care enough about the status quo to adopt this
module upstream.

- Decrease the urgency of future problems in this module: e.g.
they won't be blocking perl-5.xy upgrades and migrations anymore.

2. Keep it in sid until next time it badly breaks.

Depending on when this happens, on whether someone else than us
paid attention and took over upstream maintenance, and on the
feedback we got from step (1), then we can reconsider our options.

I certainly wouldn't mind removing it from sid now, but I know I don't represent the current consensus on our team wrt. trigger-happiness for removing packages, hence this more iterative proposal :)

I think the "remove from testing" plan is the nice way to go about it.
Let's see if it triggers reactions. IMO this module shouldn't be used in production at all, and we can indeed remove it completely, but that way,
if someone steps up it's easier to put it back.


Cheers,

--
nodens

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 21, 2020 at 10:31:53AM +0200, intrigeri wrote:

while looking for potential removal candidates, I somewhat randomly
stumbled upon libembperl-perl, whose current version in the archive is 2.5.0-15. Yes, -15, because it looks like upstream became inactive in
2014, and since then, members of our team adapted upstream code for
every change in the surrounding ecosystem:

Most of these patches were forwarded upstream, yielding no
reaction there.

So, let's face it: we've de facto been maintaining the upstream code
base since 6 years. I expect that if we keep this package in Debian,
we'll have to keep doing this on a regular basis.

Is this what we want?

Last time this came up was two years ago with #899021.

At that time Axel (explicitly cc'd just in case) was strongly against
removal.

Axel, is this still the case?
--
Niko Tyni ntyni@debian.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Niko Tyni wrote:

So, let's face it: we've de facto been maintaining the upstream code
base since 6 years. I expect that if we keep this package in Debian,
we'll have to keep doing this on a regular basis.

I won't discuss this part again.

At that time Axel (explicitly cc'd just in case) was strongly against removal.

Axel, is this still the case?

Yes, and — as I wrote to intrigeri as reply to the bug report — up to
the extent to maintain it outside the team. I'm quite sick of this
discussion.

Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Axel, hi team,

Axel Beckert (2020-08-24):

I won't discuss this part again.

Niko Tyni wrote:

At that time Axel (explicitly cc'd just in case) was strongly against
removal.

Axel, is this still the case?

Thank you, Niko, for pointing this out. At the time I started this
thread, I was not aware of the conversation that had happened on
#899021.

Yes, and — as I wrote to intrigeri as reply to the bug report — up to
the extent to maintain it outside the team. I'm quite sick of this discussion.

I understand that me starting this thread put you in the unpleasant
situation when you faced essentially the same set of arguments as you
had, in a previous discussion that had already been unpleasant for
you. I'm sorry I've hurt your feelings. And I'm sorry it took me so
long to write this message.

I can live with keeping libembperl-perl team-maintained:

- I've not put any work into this package myself so far beside trying
to triage #871729, and it's unlikely that I ever do, so the impact
on me is limited to remembering I should ignore libembperl-perl,
when I look for potentially problematic team-maintained packages.
I'll try my best.

- Looking at this topic in terms of taking care of each other and of
the group, at this point it is more important to me that we heal
the bad feelings I've triggered, than to avoid some recurring
team-maintenance work.

As a final note, making this conversation taboo forever would not seem
smart to me: a conclusion that's OK today may not be good enough in
2025, as the situation evolves with time. If one of us feels the need
to resume this conversation at some point, I hope they'll manage to
take all the relevant factors into account right from the beginning,
which I've sadly not been able to do.

Cheers!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)