Please allow me to push back on this one as well by raising a fewAlso, I think that the benefits from doing this are tiny, and just
concerns.
 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.
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.
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.
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
I think that the benefits from doing this are tiny, and just adding /usr/sbin/ to the $PATH would solve almost everything.
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 fewAlso, I think that the benefits from doing this are tiny, and just
concerns.
adding /usr/sbin/ to the $PATH would solve almost everything.
--
ciao,
Marco
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 someoneputting 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
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'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
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)?
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
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.
Two different packages must not install programs with differentThat can (should?) be interpreted as "no same basename". Otherwise root
functionality but with the same filenames
Be aware that adding Conflicts is normally not the best solution whenhttps://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
two packages provide the same files. Depending on the reason for that conflict, using alternatives or renaming the files is often a better approach.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 489 |
Nodes: | 16 (2 / 14) |
Uptime: | 50:38:52 |
Calls: | 9,671 |
Calls today: | 2 |
Files: | 13,719 |
Messages: | 6,170,364 |