Hi cacin,

I see that you are working on merging /bin and /sbin, for instance via
brltty bug #1064785. Again Fedora is pioneering this matter and their documentation is at
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.

Please allow me to push back on this one as well by raising a few
concerns.

Fundamentally, turning sbin into a symlink pointing to bin is causing
aliasing problems that we currently have a hard time fixing up for the /usr-merge. If doing this, I think we need a different technical
approach. Doing the aliasing mess again does not sound like a valid
option to me. In the /usr-merge discussion, alternatives have been
proposed. For instance, there as a proposal that would manage a symlink
farm via dpkg triggers until the aliased directory would become
unpopulated (by packages) and then turn the farm into a symlink. If
doing the symlink first, I think we need changes to dpkg before
creating such a symlink to make this approach viable.

Apart from the implementation side, this is a more user visible change.
As you complete programs in a user shell, more programs become
available. This can be good, but it can also be seen as a pollution of
your shell completion. I note that Fedora seems to have added /sbin to
the user $PATH by default, which is not what Debian has done. I do not
think we have consensus on this and would raise an objection of my own.

That said, I appreciate your work on analyzing the situation as it also uncovers tangential problems e.g. where different packages put programs
with different functionality into bin and sbin. It is up to
interpretation of Debian policy whether that should be considered an
RC-bug (10.1 "same filenames"). In general, I think that having each
program name on either bin or sbin but not both is a desirable property
and it should be easier to gain consensus on this. As we've seen with
arcstat (zfs vs nordugrid), doing so will take a long time. Where we
expect downstreams to not have hardcoded paths to programs
/usr/sbin/foo, dropping a symlink from sbin/foo -> ../bin/foo probably
is reasonable, but needs to be reviewed case by case.

As we see, this is not a single change to be working on, but multiple
related and interdependent topics. Disentangling these matters and
making the intention clear is key to moving this forward.

Regardless of whether we (as a project) want sbin merged into bin or
not, reducing conflicts (different functionality but same name) between
sbin and bin is a hard prerequisite, difficult to achieve and probably
and agreeable goal.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Feb 28, Helmut Grohne <helmut@subdivi.de> wrote:

Please allow me to push back on this one as well by raising a few
concerns.

Also, I think that the benefits from doing this are tiny, and just
adding /usr/sbin/ to the $PATH would solve almost everything.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZd8ecgAKCRDLPsM64d7X geqRAP4tR8m5mrKS9aSQ/RvKkSz3xUzkpFTqIp/wd9WMsxrFzwD/SVN+WJSsOFiA /EYn18lh3YMm+WCpgGntCVpWksyG6QQ=
=4KHk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/02/24 12:25, Ansgar 🙀 wrote:

 This can be good, but it can also be seen as a pollution of
your shell completion. I note that Fedora seems to have added /sbin to
the user $PATH by default, which is not what Debian has done. I do not
think we have consensus on this and would raise an objection of my own.

/sbin not in PATH by default makes many more veteran users unhappy.

Also non veteran users, given that certain commands in /sbin just work
fine when run as non-root (or actually should _not_ be run as root
because they trust their input). For example:

* fatlabel
* findfs
* fsck.*
* isosize
* mkfs.*
* route
* tarcat

But aside from the $PATH question, cacin work on ensuring that there are
no conflicts between /sbin and /bin is worth pursuing as these conflicts
are just bugs waiting to happen.

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Helmut,

On Wed, 2024-02-28 at 07:41 +0100, Helmut Grohne wrote:

I see that you are working on merging /bin and /sbin, for instance
via
brltty bug #1064785. Again Fedora is pioneering this matter and their documentation is at https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.

This summary is wrong. Other Linux distributions like Arch Linux have
done that over 10 years ago.

So I wouldn't call Fedora pioneering anything here (same as before with merged-/usr which many people also claim Fedora or others invented).

Apart from the implementation side, this is a more user visible
change.
As you complete programs in a user shell, more programs become
available.

I totally agree: we should aim at moving all service binaries such as
daemons which are not directly invoked by users out of PATH to
/usr/lib{,exec} or similar to make shell completion more helpful.

 This can be good, but it can also be seen as a pollution of
your shell completion. I note that Fedora seems to have added /sbin
to
the user $PATH by default, which is not what Debian has done. I do
not
think we have consensus on this and would raise an objection of my
own.

/sbin not in PATH by default makes many more veteran users unhappy.
Especially as even su (not `su -`) no longer does that (an incompatible
change in one of the last Debian releases).

Ansgar



<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div><br></div><div><span></span></div><div>Hi Helmut,</div><div><br></div><div>On Wed, 2024-02-28 at 07:41 +0100, Helmut Grohne wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:
1ex"><div>I see that you are working on merging /bin and /sbin, for instance via</div><div>brltty bug #1064785. Again Fedora is pioneering this matter and their<br></div><div>documentation is at<br></div><div><a href="https://fedoraproject.org/wiki/
Changes/Unify_bin_and_sbin">https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin</a>.<br></div></blockquote><div><br></div><div>This summary is wrong. Other Linux distributions like Arch Linux have done that over 10 years ago.</div><div><br></div><

So I wouldn't call Fedora pioneering anything here (same as before with merged-/usr which many people also claim Fedora or others invented).</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-

left:1ex"><div>Apart from the implementation side, this is a more user visible change.<br></div><div>As you complete programs in a user shell, more programs become<br></div><div>available.</div></blockquote><div><br></div><div>I totally agree: we should
aim at moving all service binaries such as daemons which are not directly invoked by users out of PATH to /usr/lib{,exec} or similar to make shell completion more helpful.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:
2px #729fcf solid;padding-left:1ex"><div>&nbsp;This can be good, but it can also be seen as a pollution of<br></div><div>your shell completion. I note that Fedora seems to have added /sbin to<br></div><div>the user $PATH by default, which is not what
Debian has done. I do not<br></div><div>think we have consensus on this and would raise an objection of my own.<br></div></blockquote><div><br></div><div>/sbin not in PATH by default makes many more veteran users unhappy. Especially as even su (not `su -`
) no longer does that (an incompatible change in one of the last Debian releases).</div><div><br></div><div>Ansgar</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote></body></
html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A few thigns I have seen in this thread:

Fedora/Arch/Whomever: I don't think it matters who thought of what first. Sometimes, it's okay to be different. I have moved all of my systems away from Slackware and Fedora/RedHat/etc. TO Debian because I think Debian does it better. Please do not
think that the "pull of RedHat" means anything. Even the larger industry is not necessarily "in love" with RedHat and its variants so much that the members of the Debian project should feel any "pull" from there, except perhaps that the reverse is also
true. If they have a GOOD idea, maybe we should do that. But the idea isn't "good" or "bad" just because Fedora is doing it (or Arch or anyone else).

So regardless of who thought of these filesystem merges (no one will get "credit" anyway), the main question is whether or not it's a good idea in the first place.

The original split between /bin and /sbin was decades ago. It was done for good reasons, and as far as I can tell, those reasons have not changed. There are still binaries (both CLI-invoked and fully automated) that non-admins have little or no
business having in their PATHs.

Also, there have been numerous occasions in my many years when I thought that merging two collections seemed "simpler," only to find that the result was so large that it became a new problem. While obviously a separate directory for each file (the other
extreme) would be silly, there is no danger of that here. Having a single directory with all executables in it sounds messy and dangerous to me, and reminds me of how MS-DOS would do things.

(Side note: Be wary of discussions that assume that daemons are never executed by hand. Postfix, dhcpd, httpd, syslog-ng, and many others have "syntax check" functions built into the daemon binaries that are often executed manually. Version checks are
often "daemon --version" or similar. Don't get caught in the assumption that "no one runs httpd by hand." Yes. They do.)

I would also suggest that what Marco said is perhaps the most important:

I think that the benefits from doing this are tiny, and just adding /usr/sbin/ to the $PATH would solve almost everything.

Not only is this the most important point (effort vs. value), but if people believe that a directory merger would be beneficial, adding the /sbin directories to users' PATHs is not only the FASTER way to accomplish that, but it is EASILY REVERSED. Far
easier to make a change to /etc/profile than to change how dozens of packages' build parameters are set.

Last thing: The idea of detecting cases where multiple binaries have the same name is a verey good one. It should also be possible to automate this effort in a number of ways. I would be happy to help with this, if it's just a matter of someone
putting in the effort. A number of "crude by effective" methods have already come to mind, some of which only require access to the repos to accomplish. (The laziest method involves having a test machine with EVERY package installed... but I'm not sure
if that is practical.)

Let me know if I can help.

--J

On Feb 28, 2024, at 05:52, Marco d'Itri <md@Linux.IT> wrote:

On Feb 28, Helmut Grohne <helmut@subdivi.de> wrote:

Please allow me to push back on this one as well by raising a few
concerns.

Also, I think that the benefits from doing this are tiny, and just
adding /usr/sbin/ to the $PATH would solve almost everything.

--
ciao,
Marco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/02/24 14:12, rhys wrote:

Last thing: The idea of detecting cases where multiple binaries have the same name is a verey good one. It should also be possible to automate this effort in a number of ways. I would be happy to help with this, if it's just a matter of someone

putting in the effort. A number of "crude by effective" methods have already come to mind, some of which only require access to the repos to accomplish. (The laziest method involves having a test machine with EVERY package installed... but I'm not sure
if that is practical.)

Contents-{all,amd64} has most of the info you need. dumat.db has _all_
the info you need (and cacin is using that).

This is a quick'n'dirty list of binaries present in both /bin and /sbin:

arping bin net/iputils-arping sbin net/arping (+ Conflicts:)
bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools
crm bin mail/crm114 sbin admin/crmsh
fai bin python/python3-flask-autoindex sbin admin/fai-client
faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:)
gearmand bin perl/gearman-server sbin misc/gearman-job-server
htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:)
ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:)
newaliases bin mail/esmtp-run sbin
mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:)
raddebug bin libs/librad0-tools sbin net/freeradius
sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:)
sethdlc bin hamradio/ax25-tools sbin comm/dahdi
siggen bin sound/siggen sbin utils/tripwire
sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:)
tcpconnect bin net/tcputils sbin misc/libbpf-tools
tcpd bin graphics/tcm sbin net/tcpd
update-locale bin web/gosa-dev sbin localization/locales

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 28, 2024 at 08:47:48AM -0600, rhys@neoquasar.org wrote:

From: Gioele Barabucci <gioele@svario.it>
Sent: Wednesday, February 28, 2024 08:22
To: debian-devel@lists.debian.org
Subject: Re: On merging bin and sbin

On 28/02/24 14:12, rhys wrote:

Last thing:  The idea of detecting cases where multiple binaries have the same name is a verey good one.  It should also be possible to automate this effort in a number of ways.  I would be happy to help with this, if it's just a matter of

someone putting in the effort.  A number of "crude by effective" methods have already come to mind, some of which only require access to the repos to accomplish.  (The laziest method involves having a test machine with EVERY package installed... but I'
m not sure if that is practical.)

Contents-{all,amd64} has most of the info you need. dumat.db has _all_
the info you need (and cacin is using that).

This is a quick'n'dirty list of binaries present in both /bin and /sbin:

arping bin net/iputils-arping sbin net/arping (+ Conflicts:)
bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools
crm bin mail/crm114 sbin admin/crmsh
fai bin python/python3-flask-autoindex sbin admin/fai-client
faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:)
gearmand bin perl/gearman-server sbin misc/gearman-job-server
htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:)
ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:)
newaliases bin mail/esmtp-run sbin mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:) raddebug bin libs/librad0-tools sbin net/freeradius
sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:) sethdlc bin hamradio/ax25-tools sbin comm/dahdi
siggen bin sound/siggen sbin utils/tripwire
sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:)
tcpconnect bin net/tcputils sbin misc/libbpf-tools
tcpd bin graphics/tcm sbin net/tcpd
update-locale bin web/gosa-dev sbin localization/locales

Are any of these (like arping) literally duplicates of the same binary for some reason? Or are they true conflicts (different binaries with the same name)?

I don't know about many of the others (although I have my suspicions), but
the two programs that just happen to both be called arping are not
the same at all: they have different functionality, conflicting
command-line options, etc.

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmXfdqAACgkQZR7vsCUn 3xO+Tg//Yp2Izi8DYlbAxyO6wRanbvkM3Ss61eg301VBrwuF8yaeQIy/4v7kJL0e 0unGjMbk0qKVxiEQNvO4c8QCBxkYYmtN7s8ZwO10NiDqZdet3+hW4QLGarBTvJ6d IbjEu5nXuq+2/OPmWcqUxGBMHlc18yG4Zb5xTQejNAIchQxPPA17VrqXsHku2CU2 fspbWobVuIUebGu8pGOF6wfmWhAY7uqUrDS6ECS6u6vZYIJA03akq6KX3xtpaCfF TkadNVVkogRExZa09u9wlPi8ZZL1/ODTCN45ycBBYW1DYXvymMcrHJk7Rfc5iFwd s9KE5YSfYrNjiX+DDhBc8INMD8CYSRA4rR23Pe1c3Lzjz3ZI1GvRgi6TL4SYJjsn DGGrIS3gRV5+eABqfwsT+RfhIYwWHDsT9M6h6HPa5DI8/JoRQPi3RkBJ+eUW18F3 5mA3RC7/aKcMp2bbUQ7oN6PAQXjzCLU4DtMG5cwHBr/zjaYIZ9d6Lu5MP2wV6p1+ TGu/0p3mOHVX8PTz21N4L1YdZY9VJMo3pDGeyMDM51PvhhEtW5L154wqg9jWIxnh RNHrf3Ffx8aojc3om0XwxMVOS2NWdQZ1fo+ZBbu7X/1EDV5+HPFiY3ggdmu5L8kz 2KgVdNCLdPKKd+FmIfiGqfvbLn2l1cwbCjGRwx6k1nK9KwULXLo=
=X83k
-

On Wed, Feb 28, 2024 at 08:47:48AM -0600, rhys@neoquasar.org wrote:

Are any of these (like arping) literally duplicates of the same binary for some reason? Or are they true conflicts (different binaries with the same name)?

arping is definitely not a duplicate, iputils-arping and arping are
different implementations.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmXfdbctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh XMIP+wcKZyEREeP76jhw+YAMfHne7zVW95Dol+hTBzgroFXNXMiMbh5dDam1uZMu 5tdYLWD0YpZCFm+UIVM5H3Uxj1xsf5Ag3sq4JFntkEqpQQTJarRFG9PnYSvsCjbE dZ87ofXxceMC7Dc4jvZPS486W65rgFFdNz86Oq1oDeGeKqF9kEM8FtGb/0weEIkK thCTtR58u8/Dn5Cy/++m7s8Fh8YTFjKw7wkDtYWjRq/fVuaHIaFjHAMl5kSr3ENS OHd8ufJN9/2kyOcB+IxK0+mhggFEGBh5N1QMI0HSOy9zjGAg7z1DxXt8R5OKs4jS LOFVT6rg4+bJ7AVH7wDuPJghwGxoxq884a9lKyQWPOgNcOJ973AnnIAMOgwgvDxy hy2ViSdReNWoy6mk4wq9AlHb1dPSWR1n6++K5V/d1Ti+iD5jPGTuG96YtjhjJJlQ YJid9yFAm4DgIAk5gAV00w97X+h/DjnC7FcNkKyac9KqloFR9zfSCpulbf///a9r Z1NGhReaGZSQAJT/A2hojLzjmwoUcJ/ODUNi/Oattkye2BuyiXhUsH99J1GeChIZ Q/gTJmR/zNtPtuImfW1V1/AFkGS6EKUMY53+zFJRpEAw+TPeEd3QRVWQ50HIK2t0 bp3+VpgsXxyZ7Bn5po3VEolwF7efWc0CzDKZTzXSqPOmy0ka
=5HJf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/02/24 19:08, Peter Pentchev wrote:

On Wed, Feb 28, 2024 at 08:47:48AM -0600, rhys@neoquasar.org wrote:

From: Gioele Barabucci <gioele@svario.it>

This is a quick'n'dirty list of binaries present in both /bin and /sbin: >>>
arping bin net/iputils-arping sbin net/arping (+ Conflicts:)

Are any of these (like arping) literally duplicates of the same binary for some reason? Or are they true conflicts (different binaries with the same name)?

I don't know about many of the others (although I have my suspicions), but the two programs that just happen to both be called arping are not
the same at all: they have different functionality, conflicting
command-line options, etc.

And that is one of issues.

Without looking, could you say which package installs `arping` in /bin
and make it available for non-root users?

Policy also has a couple of things to say. For example https://www.debian.org/doc/debian-policy/ch-files.html#binaries

Two different packages must not install programs with different
functionality but with the same filenames

That can (should?) be interpreted as "no same basename". Otherwise root
will face and ambiguous choice between the one in /bin and the one in /sbin.

In any case, many of these clashes are known. This is why some of these packages declare Conflicts: with each other. However...

Be aware that adding Conflicts is normally not the best solution when
two packages provide the same files. Depending on the reason for that conflict, using alternatives or renaming the files is often a better approach.

https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-02-28 12:25:13 +0100, Ansgar 🙀 wrote:

I totally agree: we should aim at moving all service binaries such as
daemons which are not directly invoked by users out of PATH to /usr/lib{,exec} or similar to make shell completion more helpful.

I disagree. The goal should not be to make shell completion
more helpful. The main issue about shell completion is that
most executables in /usr/bin will never be used from the shell
(so, in any case, something else needs to be done), while if
you move some binaries out of PATH, you could break existing
scripts (some of them written by the end user / admin).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Wed, 2024-02-28 at 07:41:50 +0100, Helmut Grohne wrote:

That said, I appreciate your work on analyzing the situation as it also uncovers tangential problems e.g. where different packages put programs
with different functionality into bin and sbin. It is up to
interpretation of Debian policy whether that should be considered an
RC-bug (10.1 "same filenames").

The Debian policy distinguishes between filename and pathname, and
other implementations make little sense TBH, but it could be stated
explicitly to make sure there's no room for misinterpretation.

In any case this seem like a more generic problem with conflicting
interfaces which would be nice to clarify. Some time ago I proposed
#562863, but it got eventually closed as inactive. Although I'd be
happy to work on that again if there is interest, by proposing some
wording.

In general, I think that having each
program name on either bin or sbin but not both is a desirable property
and it should be easier to gain consensus on this.

For the same implementation I think this is fine, if it provides
compatibility or for a transition period. For different implementations
or worse for different interfaces, this would be just wrong, as each one
might shadow the other depending on the system or user PATH order.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)