libpam-modules is the only pseudo-essential module that depends on libdb5.3 via its pam_userdb module.
I have never seen a system actually using this so I suggest to remove during the trixie release cylce,
i.e. dropping the Build-Depends on libdb-dev.

Alternatively, it could be split out to a separate binary package, possibly with other less used modules.

Hi Sam and Steve,

I would volunteer to provide a patch for this but only if it will be considered.

Thanks for your comments,
Bastian

    Bastian> X-Debbugs-Cc: vorlon@debian.org Hi Sam and Steve,

    Bastian> On Wed, 1 Mar 2023 18:34:50 +0100 Bastian Germann wrote:
    Bastian> I would volunteer to provide a patch for this but only if
    Bastian> it will be considered.

The patch isn't the hard part.
Honestly, I think splitting into a separate package is a lot lower risk
than  removing, but if we do that, we presumably need to have
libpam-modules depend on that package for a release cycle.

I'd definitely take a patch against the wip/debian_1.5.3 patch to split
out the module into its own package and to add a dependency from
libpam-modules to that new package. (and then we would want to remove
that dependency in the next release).

Anything more disruptive requires me to think a lot.
I'd rather not focus my energy on that, but I am open to being convinced.
I am not tracking your involvement in projects that want to reduce the
pseudo-essential set.
Is this a nice to have for you, or are you heavily involved in something
with broad consensus where this is important.

Am 13.11.23 um 03:18 schrieb Sam Hartman:

I have listed this bug in https://wiki.debian.org/Proposals/EssentialOnDiet

Your suggestion splitting out and removing after one release would be fine for me.

    Bastian> Your suggestion splitting out and removing after one
    Bastian> release would be fine for me.


Helmut, I was hoping for a sanity check.
Bastian wants to split out some code from pam.
He wants to move pam_userdb.so into its own package to remove db5.3 from
the pseudo-essential set.

I've said that I'd be fine with that if we had libpam-modules depend on
the new package for a release. (It might be okay to do something else,
but that would require surveying users or detecting breakage in ways
that require more thought than I would like to spend).

Complications:

* pam is ppseudo-essential
* usrmerge transition (pam libdir is currently /lib)

So ignoring essential and usrmerge, I think the new package  would
replace/breaks libpam-modules << the split point.

Do you have advice on what we want to do given usrmerge and essential?

Hi Sam,

thanks for reaching out.

In general terms, I welcome this change. Thanks for working on it.

I note that db5.3 also is required for building perl and python, so
while it may become possible to remove it from the pseudo-essential set,
it will likely remain in the bootstrap set.

I concur. In essence, we'd first add a new binary and source package to
the pseudo-essential set and later aim for reducing the dependency and
eventually remove that package (and its functionality) from the
pseudo-essential set.

I confirm. Since we are about to move functionality from one package to
another and from /lib to /usr/lib, this triggers a DEP17 P1 scenario.

I concur. The canonical mitigation is replacing Breaks with Conflicts
(dubbed DEP17 M7). You'll quickly figure that this is going to end badly
for pseudo-essential packages, because pam will have to Pre-Depends on
the new package. Therefore, we may use DEP17 M8. While I am quite
convinced that M8 works, I have not implemented it beyond a PoC stage,
so pam would be the first package doing. Let me quote the relevant
paragraph:

| A package that is at risk of loosing files as in P1 can set up a
| protective diversion for each affected location in the aliased form. The
| replacing preinst script has to set up these temporary diversions. When
| the replacing postinst is run, the replaced package is already upgraded
| or removed (due to associated Breaks) and it can therefore remove the
| protective diversions. These diversions only exist during an upgrade,
| but writing the maintainer scripts can be difficult to get right.
| Therefore, M7 should be preferred when applicable.

So let's say a new libpam-userdb package installs
/usr/lib/x86_64-linux-gnu/security/pam_userdb.so, it's preinst will add
a diversion for /lib/x86_64-linux-gnu/security/pam_userdb.so and its
postinst will remove this diversion. Likewise for any other file that is
taken over and also moved from / to /usr.

I very much want /usr-merge to not impact your work. It definitely will,
but let's try to keep that to a minimum. Please prepare your changes in
experimental without paying much attention to /usr-merge and then get
back to me. You may also attempt to implement M8. I'll be happy to help
and/or review.

Helmut