On Tue, Dec 29, 2020 at 06:34:35AM -0500, Sam Hartman wrote: > >>>>> "Josh" == Josh Triplett <j...@joshtriplett.org> writes: > Josh> I'm happy to contribute towards any of these paths, or another > Josh> path that would avoid expanding the pseudo-Essential set. > > Josh, I found your message fairly frustrating, because you jumped > immediately to the assumption that we want to limit the pseudo-essential > set in this way.
That wasn't the intention. I wasn't asking people to actively contribute towards that goal; I was seeking feedback on potential solutions, prior to putting in implementation effort. I was also raising the issue on -devel, because changes in Essential/pseudo-Essential typically get discussed there, and this one hadn't been as far as I could find. I realize that often, in such discussions, people reporting bugs or making feature requests may be expecting others to do the work of implementing such solutions. I was trying to avert that. I started with the baseline assumption that anyone wanting to see the pseudo-Essential set shrink or even remain at the same size would also have to step up and do the work; I wanted to start that discussion and offer to help. I wasn't assuming that everyone agreed with that goal. It certainly didn't cross my mind to think my message made any assumptions that could generate a strong negative reaction. Based on the functionality factored out of libc6 and the transitional handling of those libraries (treating them as successors and adding temporary -dev dependencies but avoiding runtime dependencies so that the libraries would be possible to remove in the future), I thought it would help to catch a case that might otherwise potentially result in a multi-release challenge in trying to remove such packages. Packages in the pseudo-Essential set, while not Essential themselves, can be quite challenging to remove once released; other packages may have implicit assumptions about their presence. So, to restate explicitly: - If we're going to handle this, I think it'll be *much* easier to do so before it hits stable. - I'm willing to help with this. - I'd like to figure out the best approach to handling this. > I'm not involved in PAM these days, so consider this the opinion of an > outside bystander. > > I think it would be most interesting to see about dllopening the NIS > support. > That seems least invasive to sysadmin experience--if you have NIS > installed at the libc6 nsswitch layer, you can also get it at the pam > layer. That seemed like the least invasive option to me, as well. Long-term, I think it may still make sense to make PAM non-Essential, but I think that'd be a substantially larger change, and one that would require more time.
