Hi Sam, On Mon, Nov 13, 2023 at 09:16:33AM -0700, Sam Hartman wrote: > Bastian> Your suggestion splitting out and removing after one > Bastian> release would be fine for me. > > > Helmut, I was hoping for a sanity check.
thanks for reaching out. > 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. 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'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). 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. > Complications: > > * pam is ppseudo-essential > * usrmerge transition (pam libdir is currently /lib) 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. > So ignoring essential and usrmerge, I think the new package would > replace/breaks libpam-modules << the split point. 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. > Do you have advice on what we want to do given usrmerge and essential? 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
