Dear Maintainer,

usrmerge will be needed to be installed upon upgrades to bookworm to
convert systems to merged /usr. It would be helpful for small installs
to be able to perform that without installing the larger perl package.

Please consider moving things that usrmerge & libfile-find-rule-perl
use from per/perl-modules to perl-base.

Specifically please move:

Fatal.pm
File/Find.pm
Tie/RefHash.pm
autodie.pm
autodie/Scope/Guard.pm
autodie/Scope/GuardStack.pm
autodie/Util.pm
if.pm

Once the above is done: libfile-find-rule-perl,
libnumber-compare-perl, libtext-glob-perl would all be able to depend
on just perl-base, and thus usrmerge will be able to just depend on
perl-base too.

In bookworm+1 you may drop these things from perl-base and add breaks
on usrmerge.

Regards,

Dimitri.

Thanks for raising this early. I'm copying the usrmerge maintainer.

I understand the concern, but I'm hesitant to do this. See below.

Quoting the Debian policy:

  Maintainers should take great care in adding any programs, interfaces,
  or functionality to essential packages. Packages may assume that
  functionality provided by essential packages is always available without
  declaring explicit dependencies, which means that removing functionality
  from the Essential set is very difficult and is almost never done. Any
  capability added to an essential package therefore creates an obligation
  to support that capability as part of the Essential set in perpetuity.

Have other avenues been investigated? How critical is the
libfile-find-rule-perl dependency - would it be hard to replace it with
something that's already in the Essential set, for instance piping from
find(1) ? Could autodie usage be replaced with explicit error handling?

Is Perl the right language to implement the migration in the first
place? A small binary with minimal external dependencies would seem
preferable.

Not by me, and I am not sure if Ubuntu needs that anymore.
Also 50 times harder to write...

How about splitting perl-modules and have perl-modules &
perl-modules-bits-and-pieces which will not be essential; perl-modules
will depend on; but also usrmerge will be able to depend on
"perl-base, perl-modules-bits-and-pieces | perl-modules" ?
And later it will be able to collapse back into perl-modules.

In Ubuntu, a choice was made to simply vendor copies of the needed
modules in the usrmerge package to reduce its dependencies. I'm not
advocating for Debian to make a similar choice.

Yes it is the right language. The implementation is concise and
correct, and it is tricky to get right.

I note that all of these except File::Find are dual life:
they are also released separately upstream on CPAN.

We have a well working process for introducing separate packages of dual
life modules to Debian, mainly used when the CPAN versions are frequently
released and gain features that have not made it into the core versions
yet. We could use the same process to introduce separate packages of
the above modules, and limit their dependencies to just perl-base.
The separate packages can later be phased out easily when this one-time
need is over.

I think this would be a clean way to handle the issue.

As for File::Find, moving it to perl-base does not seem a huge
burden. It's just 22K after stripping POD documentation (as we
customarily do for the modules in perl-base) and seems unlikely to gain
new dependencies or functionality in the future.

Alternatively, building a separate libfile-find-perl binary package from
src:perl should also be doable.

Just a note that this #985957 is also #987615 (cc'd) on the perl side.

Now that bookworm development is open I'll see what we can do there.

If something is moved to perl-base then it will use space on every
Debian system.
usrmerge being installed DOES NOT mean that the system has been
converted to merged-/usr, so there is no reason at all to keep it around
after it has been used.

My suggestion in #987615 (which I also copied to usrmerge@pdo, being
unaware of #985957) is to introduce separate packages of the usrmerge
dependencies, and limit their dependencies to perl-base only. This does
not grow perl-base and can be phased out later, so it does not impose
a permanent cost on everybody.

Seems to me, that simply vendoring the necessary perl modules in the
usrmerge package would be a better, simpler and more lightweight approach to
packaging those all invidually as separate packages.

Regards,
Michael

Yeah, you're probably right, particularly as I haven't got around to doing
much about this so far. I'm fine with that approach FWIW.

I did try out the separate package plan at home at one point, and got
things working with seven modified or introduced packages (well, eight
if you count the usrmerge package too.) Here's some notes, maybe they
will save somebody some work even if this is not the chosen path.

There's two branches to the usrmerge dependencies:

libautodie-perl (would need a separate package)
    libif-perl  (would need a separate package)
    libtie-refhash-perl (would need a separate package)

libfile-find-rule-perl (would need dependency modifications)
    libfile-find-perl  (would need a separate package)
    libnumber-compare-perl (would need dependency modifications)
    libtext-glob-perl (would need dependency modifications)

Happily all these modules are pure Perl, which makes things a bit easier.

The libnumber-compare-perl and libtext-glob-perl modifications are trivial
(override dh_perl to dh_perl -d). I suggest modifying at least those
two packages instead of bundling them.

I'm copying the debian-perl list for some visibility.

Both packages uploaded with the suggested 'dh_perl -d' change.


Cheers,
gregor