-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[rfc] drop everything that conflicts with util-linux #999
Comments
Hmmm. Can you please list the conflicts with each of those packages? |
These are the conflicts with coreutils, AFAICS: $ ( \
apt-file show coreutils \
| grep /bin/ \
| awk '{print $2}' \
| sed s/.usr.bin.//;
find src/ -type f \
| grep '\.c$' \
| sed s/src.// \
| sed s/.c$//;
) \
| sort \
| uniq -d;
groups
id And with util-linux, at least on my Debian system: $ ( \
apt-file show util-linux \
| grep /bin/ \
| awk '{print $2}' \
| sed s/.usr.bin.//;
find src/ -type f \
| grep '\.c$' \
| sed s/src.// \
| sed s/.c$//;
) \
| sort \
| uniq -d;
su |
Can you please show how much code it takes to remove these downstream? And how much it would take to do it upstream?
Can you clarify that? |
Related: #464 |
Thanks for looking at this, and sorry for being slow. Right. util-linux on Void linux also has There's e.g. a patch in Arch linux https://gitlab.archlinux.org/archlinux/packaging/packages/shadow/-/raw/main/0001-Disable-replaced-tools-their-man-pages-and-PAM-integ.patch?ref_type=heads that one could look at. Lastly, I meant that (last time I checked) shadow does not respect the |
Thanks!
Thanks again!
Hmmm, I don't know much about autotools. Could you point to documentation or standards that document |
Sorry, for the last I just meant the following (standard configure):
|
Ahhh, now it makes sense. Yeah, I agree not respecting Do you want to send a patch for that? |
Personally I don't see a reason for upstream shadow to maintain such a list.
Almost nothing. And I feel like distributions have to pick which tools they want. Some might want X from here and Y from there. I don't think its like "take all the tools from shadow" or "take all the tools from util-linux". And to have such a configure switch for 3 projects..and keep it updated..just doesn't seem worth it. In case of openSUSE you can see the |
The linked patch from Arch also deals with it, but we may want to be more careful, as in the past this issue broke things, see e.g. #197 Still respecting the configure option should be possible. |
I disagree with that. Patching or removing stuff by hand is not good, and requires extra work to maintain. |
No, I don't think we want to go this route. If there are programs which we feel should be used from util-linux or another suite, then I'd prefer to mark those deprecated and eventually drop them here. Why would we want to continue duplicating effort maintaining the code? Switching debian to util-linux/su however did come with some regressions (reportedly, I did not |
Even better. |
@dkwo Did you do some research/comparison regarding:
? |
I expect some distributions to not like the idea: Those that don't use PAM need shadow/su. I wonder if util-linux/su has any feature (or lack of) that some distros decided to switch to it (didn't check). Regarding the coreutils stuff, I expect their stuff to be more widely used than ours, so that might be easier to drop. Busybox also has id(1), so that's a very good candidate for saying good bye. Busybox doesn't seem to have groups(1), though (edit: it does exist; the source I checked was wrong or old). We could add an issue for discussing the removal of id(1) (if none of you disagree), and leave this one for the rest of the discussion. I think that should be already an improvement for @dkwo (and also IMO, FWIW; less stuff to maintain). Edit: add some research about id(1) and groups(1) coreutils/id has existed since back in 1992:
busybox/id has existed since 2000:
busybox/groups exists since 2011:
|
How about then dropping everything, except for |
Can you indicate specifically which binaries you want to drop from shadow? |
Re su: if the configure option I'd like to drop |
I prefer to go step by step. Let's discuss what to do with coreutils clashes, and then discuss util-linux. With coreutils, we have the following clashes: alx@debian:~$ ( \
find ~/src/gnu/coreutils/master/src/ -type f \
| grep '\.c$' \
| sed s/.home.alx.src.gnu.coreutils.master.src.// \
| sed s/.c$//; \
find ~/src/shadow/shadow/master/src/ -type f \
| grep '\.c$' \
| sed s/.home.alx.src.shadow.shadow.master.src.// \
| sed s/.c$//; \
) \
| sort \
| uniq -d;
groups
id I will open an issue for these. |
Thanks for opening the other PR and going one step at a time. I think this will speed up the process as we may face some challenges with some of the removals. |
JFYI: openSUSE uses the binaries from following packages: shadow
coreutils
util-linux
removed
|
Did you miss id(1)? |
Indeed I did :) Added it now. |
This RFC is connected with issue #985. I do not mind if we have this API in linux-utils but we should have it somewhere. Lot of projects depend on libuser when changing full name or shell, but unfortunately libuser is not actively developed, only maintained. Apart from using libuser (compile time option), the linux-utils has also its own implementation of those functions, but not exported as public API. |
When I last checked in Debian, the vigr, vipw programs from util-linux were not as nice as the shadow versions. Having said that, it certainly is nicer if only one project would have these programs - for Debian, it doesn't matter if it will be src:shadow or src:util-linux. |
Thans. I suppose having them from shadow makes sense anyway, since it ships passwd etc. But if the util-linux versions are brought to feature parity (with no risk of regressions in someone's obscure closet), I'd be only too happy to drop the shadow ones. |
There are commands (as well as their pam files and man pages) that conflict with either coreutils or util-linux.
Right now, linux distros either remove them by hand after building, or patch the makefile.
It would be far better to have these as a configure option, either per command or in larger groups.
As a byproduct, one could also try to respect the configure options for /usr/bin etc.
cc @alejandro-colomar
The text was updated successfully, but these errors were encountered: