Bug#1086809: ucfq has undeclared dependency on a full perl installation: Getopt/Long/Parser.pm not present in perl-base

[Niko Tyni]

Control: reassign -1 perl-base 5.40.0-6
Control: retitle -1 perl-base: reinstate Getopt::Long::Parser

On Wed, Nov 06, 2024 at 11:17:27AM +0000, Mark Hindley wrote:
> Package: ucf
> Version: 3.0043+nmu1
> Severity: serious
> Justification: Undeclared dependency, breaks unrelated packages

> ucfq uses the perl module Getopt/Long/Parser.pm[1]. In perl 5-40 (which bundled
> Getopt-Long 2.57) this module has been split to a separate file [2]. Relying on
> the Essential perl-base being installed is now inadequate:

Thanks for the report and for copying me.

Indeed this works on bookworm with just perl-base but dies
on trixie/sid:

# perl -MGetopt::Long -E 'say "ok" if Getopt::Long::Parser->new'

> Either ucf needs to depend on perl or perl-base needs to include
> Getopt/Long/Parser.pm. Copying Niko for his opinion, I suppose other packages
> may be impacted by this change?

This was an accidental change to the Essential functionality of
perl-base. We do have some checks in place to notice if perl-base becomes
no longer self contained, but the failure mode is subtle enough that we
missed it.

I don't think ucfq can easily depend on things outside the essential set,
as it's commonly used in 'postrm purge' logic, where such dependencies are
not guaranteed to be satisfied. A quick search on codesearch.debian.net
suggests not all postrm scripts catch ucfq failures gracefully (nor are
they currently expected to in my understanding.) And if we still tried
fix this in ucfq, we'd also have to consider partial upgrades where
perl-base might be upgraded before ucf.

So I think this is a bug in perl-base, and we need to fix it there
by reinstating Getopt::Long::Parser. As the policy puts it, we have
an obligation to support the module as part of the Essential set in
perpetuity.

Reassigning.
-- 
Niko