Hello Laurent Bigonville. Thanks for opening this bug report. I remember we've touched on this subject inside another bug report but I feel it's useful to have a separate on-topic discussion about this...
On Tue, Aug 02, 2016 at 11:01:56AM +0200, Laurent Bigonville wrote: > Package: util-linux > Version: 2.28-6 > Severity: normal > > Hi, > > ATM, on debian, login, su, ... are provided by the shadow package. Currently we use the --disable-login --disable-nologin and --disable-su configure flags when building util-linux in Debian because these are provided by the "login" package. We also use --disable-chfn-chsh as that's provided by the "passwd" package. Both "login" and "passwd" are built from src:shadow. > > It seems that all other distribution are using the implementations from > util-linux. Yes. > > Shouldn't debian do the same and shouldn't we build the "login" from > util-linux? It's not only these tools, but the entile login and authentication stack seems to have a different origin in Debian compared to other distributions. I'm sure you for example know better than me about the history about our PAM deviations from other distributions. I think this issue should be viewed in a broader perspective. > > This should of course be coordinated with the maintainer of the shadow > package. Feedback from the shadow maintainer(s) would be very welcome/useful on this bug report. I think we should not only focus about a few tools that overlap between shadow and util-linux, but view this from a bigger perspective. Someone needs to draw the bigger picture, come up with a plan for how we'd like the future map to look like (and why we should do all this work). Also someone needs to make sure the different implementation of the tools are actually 100% compatible or what migrations we need to handle on package upgrades. Please note that while "login" is Essential: yes, the "passwd" package is not. Things to keep in mind when expanding util-linux is that all tools then become Essential: yes which I think is unfortunate as we should strive to keep the essential set as small as possible. A package split is probably needed here and that's always hairy to come up with the right plan that will fit the future developments. Likely revamping the existing package split would be useful while at it. (Some kind of history lesson on why we deviated would likely also be useful. My limited software archeology experince has taught me that it's often a very good way to detect and fix problems before introducing them when doing these kind of switchovers. The devil is often in the details. Those details can often be found when seeking the answers to questions like: Was there a fork or where things developed completely separately? Why where things developed separately? What are the main philosophical differences between the development groups? etc...) I have no personal objections to moving to the util-linux implementation as they're actively maintained upstream, but I'm not going to actively work on this myself. I'm thus tempted to tag this bug report as wontfix for now until someone lays out information on the "why" and the "how" and hopefully the interest is also high enough that someone provides a tested patch. (If you think it sounds like you doing this work means you risk ending up co-maintaining util-linux in Debian, then yes! New co-maintainers welcome/needed.) Regards, Andreas Henriksson
