Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, 2024-02-23 at 12:57 -0500, Stephen Smoogen wrote: > > > On Fri, 23 Feb 2024 at 08:04, Sérgio Basto wrote: > > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > > > > No. This is one of those many myths about the "Unix FHS". And it > > > doesn't even matter much these days anyway, since most newer > > > administrative tools don't install in sbin anyway. > > > > > > > name it one , I'm not aware. > > > > Fedora old school (or just me I don't know ) don't use sudo , sudo > > is a > > bad idea that came from Ubuntu and turn computer much more insecure > > , > > > > > sudo has been part of the Red Hat/Fedora family since Red Hat Linux > 7.0 > https://archive.download.redhat.com/pub/redhat/linux/7.0/en/os/i386/R > edHat/RPMS/ (2000-09) and had been in powertools since at least > 5.2 https://archive.download.redhat.com/pub/redhat/linux/5.2/en/power > tools/i386/ (1998-11). Both of those dates vastly predate Ubuntu. > While they had been part of Debian before that they were included in > Powertools in 5 due to requests for it being used on Unix systems > which were being replaced with Red Hat Linux. [sudo was already a > preferred tool in various university and corporate environments > because it did allow for all kinds of policy decisions which were > easily updated versus the standard at that time to make a chroot > wrapper and control via group permissions. Many times these wrappers > were the most insecure thing on a system. ] I don't use sudo or my regular user is not in sudo users , sudo is needed for others things like wheel group and always have been present in Linux I mean using sudo and can't login as root or root don't have password , like in Ubuntu model and if you are admin you do sudo for everything . > > since if a regular user is compromised the access to all computer > > is > > much more easier . > > > > > https://xkcd.com/1200/ > This xkcd is not new for me and made me think, I already stated my opinion don't want lose much time on this subject > > And PATH at root user have sbin and PATH of regular user should not > > have /sbin/ > > > > but checking we got this pearl in /etc/profile > > > > > > if [ "$EUID" = "0" ]; then > > pathmunge /usr/sbin > > pathmunge /usr/local/sbin > > else > > pathmunge /usr/local/sbin after > > pathmunge /usr/sbin after > > fi > > > > > > > There have been holy wars over /usr/sbin:/sbin:/usr/local/bin for as > long as I have been a systems administrator in the 1980's. Different > schools of thought have their world view of when/who/how people > should have access to it and it would be even split into which Unix > you used because of what was needed to act per system. > > In the end, this choice tends to be deeply personal where each person > assumes the world should follow their model and then get > increasingly angry that is not the case. I have seen it create > complete forks of an operating system due to needing to compile in > such paths in various tools. > > > > > -- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Once upon a time, Stephen Smoogen said: > On Fri, 23 Feb 2024 at 08:04, Sérgio Basto wrote: > > Fedora old school (or just me I don't know ) don't use sudo , sudo is a > > bad idea that came from Ubuntu and turn computer much more insecure , > > sudo has been part of the Red Hat/Fedora family since Red Hat Linux 7.0 > https://archive.download.redhat.com/pub/redhat/linux/7.0/en/os/i386/RedHat/RPMS/ > (2000-09) and had been in powertools since at least 5.2 > https://archive.download.redhat.com/pub/redhat/linux/5.2/en/powertools/i386/ > (1998-11). Both of those dates vastly predate Ubuntu. To add: sudo itself pre-dates Linux itself by around 11 years - sudo was created closer to when su was created than to when the Linux kernel was created. sudo's config syntax is a little awkward, but it is a far superior solution over su when it comes to security. sudo _can_ be configured insecurely, but that's a function of who configures it and how, not the tool itself. You could also make su insecure with bad configuration. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, 23 Feb 2024 at 08:04, Sérgio Basto wrote: > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > > No. This is one of those many myths about the "Unix FHS". And it > > doesn't even matter much these days anyway, since most newer > > administrative tools don't install in sbin anyway. > > > > name it one , I'm not aware. > > Fedora old school (or just me I don't know ) don't use sudo , sudo is a > bad idea that came from Ubuntu and turn computer much more insecure , > sudo has been part of the Red Hat/Fedora family since Red Hat Linux 7.0 https://archive.download.redhat.com/pub/redhat/linux/7.0/en/os/i386/RedHat/RPMS/ (2000-09) and had been in powertools since at least 5.2 https://archive.download.redhat.com/pub/redhat/linux/5.2/en/powertools/i386/ (1998-11). Both of those dates vastly predate Ubuntu. While they had been part of Debian before that they were included in Powertools in 5 due to requests for it being used on Unix systems which were being replaced with Red Hat Linux. [sudo was already a preferred tool in various university and corporate environments because it did allow for all kinds of policy decisions which were easily updated versus the standard at that time to make a chroot wrapper and control via group permissions. Many times these wrappers were the most insecure thing on a system. ] > since if a regular user is compromised the access to all computer is > much more easier . > https://xkcd.com/1200/ > And PATH at root user have sbin and PATH of regular user should not > have /sbin/ > > but checking we got this pearl in /etc/profile > > > if [ "$EUID" = "0" ]; then > pathmunge /usr/sbin > pathmunge /usr/local/sbin > else > pathmunge /usr/local/sbin after > pathmunge /usr/sbin after > fi > > There have been holy wars over /usr/sbin:/sbin:/usr/local/bin for as long as I have been a systems administrator in the 1980's. Different schools of thought have their world view of when/who/how people should have access to it and it would be even split into which Unix you used because of what was needed to act per system. In the end, this choice tends to be deeply personal where each person assumes the world should follow their model and then get increasingly angry that is not the case. I have seen it create complete forks of an operating system due to needing to compile in such paths in various tools. > > -- > Sérgio M. B. > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, 2024-02-23 at 09:17 -0500, Neal Gompa wrote: > On Fri, Feb 23, 2024 at 8:04 AM Sérgio Basto > wrote: > > > > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > > wrote: > > > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > > > wrote: > > > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Wiki -> > > > > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > > > the packager guidelines for use of /sbin > > > > > > (and /usr/sbin) in additional locations from > > > > > > those involved directly with installing binaries. > > > > > > > > > > > > In particular, I am thinking of the sysusers > > > > > > examples where the use of /sbin/nologin > > > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > > > There are almost certainly other places > > > > > > in the docs/guidelines. > > > > > > > > > > > > The documentation updates are always > > > > > > the most annoying in my experience. > > > > > > > > > > We cannot change this without breaking backward > > > > > compatibility. > > > > > It'll > > > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > > > > That is a good argument to not change it , why we need break > > > > backward > > > > compatibility ? > > > > > > > > > > Nah. It just means we don't change any configuration or PATH > > > stuff, > > > which is fine because the sbin -> bin symlink will cover it. > > > > > > > I strongly disagree with you , we should avoid break backward > > compatibility , unless we got a very good reason , which is not the > > case > > > > We're not breaking backward compatibility. We would install a symlink > pointing sbin to bin, which ensures any absolute path usage of > binaries formerly in sbin will still work. Good > > > > is not sbin for super users and bin for users ? > > > > > > > > > > No. This is one of those many myths about the "Unix FHS". And it > > > doesn't even matter much these days anyway, since most newer > > > administrative tools don't install in sbin anyway. > > > > > > > name it one , I'm not aware. > > > > Sure: dnf. Not convinced, dnf repoquery can be used by any user. I don't see any major problem but also I don't see any great benefit, so I don't think we should change that, as it will be, most likely, a lot of work to everyone -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, Feb 23, 2024 at 8:04 AM Sérgio Basto wrote: > > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > wrote: > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > > wrote: > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > > > > > > wrote: > > > > > > > > > > > > Wiki -> > > > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > > the packager guidelines for use of /sbin > > > > > (and /usr/sbin) in additional locations from > > > > > those involved directly with installing binaries. > > > > > > > > > > In particular, I am thinking of the sysusers > > > > > examples where the use of /sbin/nologin > > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > There are almost certainly other places > > > > > in the docs/guidelines. > > > > > > > > > > The documentation updates are always > > > > > the most annoying in my experience. > > > > > > > > We cannot change this without breaking backward compatibility. > > > > It'll > > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > That is a good argument to not change it , why we need break > > > backward > > > compatibility ? > > > > > > > Nah. It just means we don't change any configuration or PATH stuff, > > which is fine because the sbin -> bin symlink will cover it. > > > > I strongly disagree with you , we should avoid break backward > compatibility , unless we got a very good reason , which is not the > case > We're not breaking backward compatibility. We would install a symlink pointing sbin to bin, which ensures any absolute path usage of binaries formerly in sbin will still work. > > > is not sbin for super users and bin for users ? > > > > > > > No. This is one of those many myths about the "Unix FHS". And it > > doesn't even matter much these days anyway, since most newer > > administrative tools don't install in sbin anyway. > > > > name it one , I'm not aware. > Sure: dnf. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > wrote: > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > wrote: > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > > > > wrote: > > > > > > > > > > Wiki -> > > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > One additional item to consider is to review > > > > the packager guidelines for use of /sbin > > > > (and /usr/sbin) in additional locations from > > > > those involved directly with installing binaries. > > > > > > > > In particular, I am thinking of the sysusers > > > > examples where the use of /sbin/nologin > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > There are almost certainly other places > > > > in the docs/guidelines. > > > > > > > > The documentation updates are always > > > > the most annoying in my experience. > > > > > > We cannot change this without breaking backward compatibility. > > > It'll > > > have to stay that way until RHEL 9 falls out of support. > > > > > > That is a good argument to not change it , why we need break > > backward > > compatibility ? > > > > Nah. It just means we don't change any configuration or PATH stuff, > which is fine because the sbin -> bin symlink will cover it. > I strongly disagree with you , we should avoid break backward compatibility , unless we got a very good reason , which is not the case > > is not sbin for super users and bin for users ? > > > > No. This is one of those many myths about the "Unix FHS". And it > doesn't even matter much these days anyway, since most newer > administrative tools don't install in sbin anyway. > name it one , I'm not aware. Fedora old school (or just me I don't know ) don't use sudo , sudo is a bad idea that came from Ubuntu and turn computer much more insecure , since if a regular user is compromised the access to all computer is much more easier . And PATH at root user have sbin and PATH of regular user should not have /sbin/ but checking we got this pearl in /etc/profile if [ "$EUID" = "0" ]; then pathmunge /usr/sbin pathmunge /usr/local/sbin else pathmunge /usr/local/sbin after pathmunge /usr/sbin after fi -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, Feb 23, 2024 at 5:44 AM Roy Bekken wrote: > > On fredag 23. februar 2024 02:36:38 CET Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto wrote: > > > > > > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > > the packager guidelines for use of /sbin > > > > > (and /usr/sbin) in additional locations from > > > > > those involved directly with installing binaries. > > > > > > > > > > > > > > > > > > > > In particular, I am thinking of the sysusers > > > > > examples where the use of /sbin/nologin > > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > > > > > > > > > > > There are almost certainly other places > > > > > in the docs/guidelines. > > > > > > > > > > > > > > > > > > > > The documentation updates are always > > > > > the most annoying in my experience. > > > > > > > > > > > > > > > > We cannot change this without breaking backward compatibility. It'll > > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > > > > > > > That is a good argument to not change it , why we need break backward > > > compatibility ? > > > > > > > > > > > > Nah. It just means we don't change any configuration or PATH stuff, > > which is fine because the sbin -> bin symlink will cover it. > > > > > Shouldn't sbin be removed from the path with this change? > > The only reason normal users have sbin in the first place is because of the > convenience of tab completion with sudo. > We *could*, but we don't really have to. > When normal users got sbin, it was important that it was at the end of the > variable or it would break consolehelper. I’m not sure if consolehelper is > ever used anymore but its still part the repo. > consolehelper is still used for mock and a few other things. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On fredag 23. februar 2024 02:36:38 CET Neal Gompa wrote: > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto wrote: > > > > > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > > wrote: > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > wrote: > > > > > > > > > > > > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > > > > > > > > > > > > > > > > One additional item to consider is to review > > > > the packager guidelines for use of /sbin > > > > (and /usr/sbin) in additional locations from > > > > those involved directly with installing binaries. > > > > > > > > > > > > > > > > In particular, I am thinking of the sysusers > > > > examples where the use of /sbin/nologin > > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > > > > > > > > > > > There are almost certainly other places > > > > in the docs/guidelines. > > > > > > > > > > > > > > > > The documentation updates are always > > > > the most annoying in my experience. > > > > > > > > > > > > We cannot change this without breaking backward compatibility. It'll > > > have to stay that way until RHEL 9 falls out of support. > > > > > > > > > > That is a good argument to not change it , why we need break backward > > compatibility ? > > > > > > > Nah. It just means we don't change any configuration or PATH stuff, > which is fine because the sbin -> bin symlink will cover it. > > Shouldn't sbin be removed from the path with this change? The only reason normal users have sbin in the first place is because of the convenience of tab completion with sudo. When normal users got sbin, it was important that it was at the end of the variable or it would break consolehelper. I’m not sure if consolehelper is ever used anymore but its still part the repo. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto wrote: > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > > wrote: > > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > wrote: > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > One additional item to consider is to review > > > the packager guidelines for use of /sbin > > > (and /usr/sbin) in additional locations from > > > those involved directly with installing binaries. > > > > > > In particular, I am thinking of the sysusers > > > examples where the use of /sbin/nologin > > > should, perhaps, be changed to /usr/bin/nologin. > > > > > > There are almost certainly other places > > > in the docs/guidelines. > > > > > > The documentation updates are always > > > the most annoying in my experience. > > > > We cannot change this without breaking backward compatibility. It'll > > have to stay that way until RHEL 9 falls out of support. > > > That is a good argument to not change it , why we need break backward > compatibility ? > Nah. It just means we don't change any configuration or PATH stuff, which is fine because the sbin -> bin symlink will cover it. > is not sbin for super users and bin for users ? > No. This is one of those many myths about the "Unix FHS". And it doesn't even matter much these days anyway, since most newer administrative tools don't install in sbin anyway. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote: > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster > wrote: > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > wrote: > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > One additional item to consider is to review > > the packager guidelines for use of /sbin > > (and /usr/sbin) in additional locations from > > those involved directly with installing binaries. > > > > In particular, I am thinking of the sysusers > > examples where the use of /sbin/nologin > > should, perhaps, be changed to /usr/bin/nologin. > > > > There are almost certainly other places > > in the docs/guidelines. > > > > The documentation updates are always > > the most annoying in my experience. > > We cannot change this without breaking backward compatibility. It'll > have to stay that way until RHEL 9 falls out of support. That is a good argument to not change it , why we need break backward compatibility ? is not sbin for super users and bin for users ? -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 28, 2024 at 2:54 PM Gary Buhrmaster wrote: > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > One additional item to consider is to review > the packager guidelines for use of /sbin > (and /usr/sbin) in additional locations from > those involved directly with installing binaries. > > In particular, I am thinking of the sysusers > examples where the use of /sbin/nologin > should, perhaps, be changed to /usr/bin/nologin. > > There are almost certainly other places > in the docs/guidelines. > > The documentation updates are always > the most annoying in my experience. Please, don't. Deliberately ignoring years of the File System Hierarchy for some big-vision architectural ideal is one of the things that has consumed thousands if not millions of man-hours of sysadmin time since UNIX was invented. Nico Kadel-Garcia -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 28, 2024 at 8:15 PM Neal Gompa wrote: > We cannot change this without breaking backward compatibility. It'll > have to stay that way until RHEL 9 falls out of support. Is someone collecting the cleanup TODO list for ~ mid-2032? (schedules subject to change, of course) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster wrote: > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > One additional item to consider is to review > the packager guidelines for use of /sbin > (and /usr/sbin) in additional locations from > those involved directly with installing binaries. > > In particular, I am thinking of the sysusers > examples where the use of /sbin/nologin > should, perhaps, be changed to /usr/bin/nologin. > > There are almost certainly other places > in the docs/guidelines. > > The documentation updates are always > the most annoying in my experience. We cannot change this without breaking backward compatibility. It'll have to stay that way until RHEL 9 falls out of support. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > One additional item to consider is to review the packager guidelines for use of /sbin (and /usr/sbin) in additional locations from those involved directly with installing binaries. In particular, I am thinking of the sysusers examples where the use of /sbin/nologin should, perhaps, be changed to /usr/bin/nologin. There are almost certainly other places in the docs/guidelines. The documentation updates are always the most annoying in my experience. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Ben Beasley writes:
> sestatus
This is based on upstream commit d464187c37529c [1]:
policycoreutils: sestatus belongs to bin not sbin
It is quite useful even to non-privileged users and doesn't require any
privileges to work, except for maybe -v.
Some tools hard code the old path, so a compatibility symlink is also
created.
- install -m 755 sestatus $(DESTDIR)$(SBINDIR)
+ # Some tools hard code /usr/sbin/sestatus ; add a compatibility symlink
+ # install will overwrite a symlink, so create the symlink before calling
+ # install to allow distributions with BINDIR == SBINDIR
+ ln -sf --relative $(DESTDIR)$(BINDIR)/sestatus $(DESTDIR)$(SBINDIR)
+ install -m 755 sestatus $(DESTDIR)$(BINDIR)
So it's should be ready for BINDIR == SBINDIR from upstream POV.
But it can't be built [2] without %{_sbindir}/sestatus until this change
is implemented:
error: Installed (but unpackaged) file(s) found:
/usr/sbin/sestatus
Installed (but unpackaged) file(s) found:
/usr/sbin/sestatus
[1]
https://github.com/SELinuxProject/selinux/commit/d464187c37529ca75fd417174f39ce0eaf13efb5
[2] https://src.fedoraproject.org/rpms/policycoreutils/pull-request/41
Petr
>
> That should be a reasonably accurate list of the executables that need
> investigation, and for which the packages that provide them probably
> need some kind of modification.
>
> On 1/7/24 10:47, Gary Buhrmaster wrote:
>> On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote:
>>> Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>>>
>> I do not see as part of the plan a process to
>> go through all Fedora packages and identifying
>> binaries in /usr/bin that have the same name
>> as a binary in /usr/sbin (from the same, or
>> different packages) such that the packager
>> (or the multiple packages) will need to
>> coordinate the changes (perhaps by engaging
>> upstream).
>>
>> I agree that there should be few, but
>> identifying impacts in advance provides
>> for a better decision process, and minimizes
>> the last minute work that packagers need
>> to do (they will have a longer warning and
>> preparation time).
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
I attempted a quick check: $ repoquery -q --repo=rawhide -l -a | tee >( grep -E '^/usr/bin/[^/]+$' | sort -u | xargs -n 1 basename > bin.txt ) | grep -E '^/usr/sbin/[^/]+$' | sort -u | xargs -n 1 basename > sbin.txt $ wc -l bin.txt sbin.txt 31229 bin.txt 2998 sbin.txt 34227 total $ comm -1 -2 bin.txt sbin.txt arping backintime-qt-root bat beesu chkrootkit etherape exabgp-healthcheck faxq gearmand hcidump hddtemp hunt ifstat iscsistart lshw-gui lspci makemap mate-system-log msktutil named-checkconf named-checkzone named-compilezone pidof ping ptdump rdistd rhino rpcbind rpcinfo sendfax sestatus setup sievec subscription-manager system-switch-java tmpwatch tracepath udevadm updatedb v4l-conf vpnc vpnc-disconnect That should be a reasonably accurate list of the executables that need investigation, and for which the packages that provide them probably need some kind of modification. On 1/7/24 10:47, Gary Buhrmaster wrote: On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin I do not see as part of the plan a process to go through all Fedora packages and identifying binaries in /usr/bin that have the same name as a binary in /usr/sbin (from the same, or different packages) such that the packager (or the multiple packages) will need to coordinate the changes (perhaps by engaging upstream). I agree that there should be few, but identifying impacts in advance provides for a better decision process, and minimizes the last minute work that packagers need to do (they will have a longer warning and preparation time). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On 09/01/2024 18.53, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jan 09, 2024 at 03:51:26PM +0100, Sjoerd Mullender wrote: On 08/01/2024 14.41, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jan 08, 2024 at 10:02:55AM +0200, Panu Matilainen wrote: On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin I agree unifying the *programs* to a single directory makes sense. But I fail to see anything good come out of bringing all those system daemon executables into every users path. To clarify: they already *are* in every user's path, see https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Detailed_Description, third para. Not quite true: If you're using lightdm as display manager, the PATH is initialized to /usr/local/bin:/usr/bin:/bin, at least on Fedora 39. Please open a bug against lightdm ;) https://bugzilla.redhat.com/show_bug.cgi?id=2257618 -- Sjoerd Mullender -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Tue, Jan 9, 2024 at 5:51 PM Zbigniew Jędrzejewski-Szmek wrote: > $ dnf5 repoquery --whatprovides '/usr/sbin/exabpg-*' > (no answer) > If you spell exabgp correctly (not exabpg) it works somewhat better. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Tue, Jan 09, 2024 at 03:51:26PM +0100, Sjoerd Mullender wrote: > On 08/01/2024 14.41, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jan 08, 2024 at 10:02:55AM +0200, Panu Matilainen wrote: > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney > > > > wrote: > > > > > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > > > > > > > I agree unifying the *programs* to a single directory makes sense. But I > > > fail to see anything good come out of bringing all those system daemon > > > executables into every users path. > > > > To clarify: they already *are* in every user's path, see > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Detailed_Description, > > third para. > > Not quite true: If you're using lightdm as display manager, the PATH is > initialized to /usr/local/bin:/usr/bin:/bin, at least on Fedora 39. Please open a bug against lightdm ;) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Tue, Jan 09, 2024 at 02:34:05PM +0100, Petr Pisar wrote:
> V Mon, Jan 08, 2024 at 09:42:41PM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > On Mon, Jan 08, 2024 at 03:26:45PM +, Gary Buhrmaster wrote:
> > > On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > > $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
> > > > '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort |
> > > > uniq -c | rg -w 2
> > > >
> > > > says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> > > > "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> > > > need just to be dropped to prevent a FTBFS. I added this list with
> > > > four packages to the Scope section.
> > >
> > > Thanks, but I think the query does not produce
> > > all possible results, as I know for a fact that there is
> > > a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
> > > and a (different) /usr/bin/exabgp-healthcheck file
> > > (which is why I prompted my query, as I expect
> > > there might be others (I plan to fix exabgp)).
> >
> > Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp.
(That was supposed to be dnf-4 and dnf5.)
> > Either a bug or I'm doing something wrong.
> >
> Thanks for testing DNF5. I notified DNF5 maintainers
> .
$ dnf5 repoquery --whatprovides /usr/sbin/exabgp-healthcheck
exabgp-0:4.2.21-7.fc39.noarch
exabgp-0:4.2.21-8.fc39.noarch
$ dnf5 repoquery --whatprovides '/usr/sbin/exabpg-*'
(no answer)
But
$ dnf5 repoquery --whatprovides '/usr/sbin/mkfs*'
dosfstools-0:4.2-7.fc39.x86_64
e2fsprogs-0:1.47.0-2.fc39.x86_64
xfsprogs-0:6.4.0-1.fc39.i686
xfsprogs-0:6.4.0-1.fc39.x86_64
So a glob works in some cases but not others? I'm confused.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On 08/01/2024 14.41, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jan 08, 2024 at 10:02:55AM +0200, Panu Matilainen wrote: On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin I agree unifying the *programs* to a single directory makes sense. But I fail to see anything good come out of bringing all those system daemon executables into every users path. To clarify: they already *are* in every user's path, see https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Detailed_Description, third para. Not quite true: If you're using lightdm as display manager, the PATH is initialized to /usr/local/bin:/usr/bin:/bin, at least on Fedora 39. This would seem like a good opportunity to move stuff that isn't supposed to be directly run as part of normal usage under /usr/libexec. I'm sure there are exceptions but as a rule of thumb, if it has a systemd service file then it should no longer be in %_sbindir. This was also mentioned by Matthew Miller on discussion.fp.o and I agree, but I think that that's an orthogonal issue. Individual maintainers should evaluate this and do the move if they really think that no one is calling the binary directly. This can be done before or after the proposed change. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Sjoerd Mullender -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
V Mon, Jan 08, 2024 at 09:42:41PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Jan 08, 2024 at 03:26:45PM +, Gary Buhrmaster wrote:
> > On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
> > > '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort |
> > > uniq -c | rg -w 2
> > >
> > > says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> > > "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> > > need just to be dropped to prevent a FTBFS. I added this list with
> > > four packages to the Scope section.
> >
> > Thanks, but I think the query does not produce
> > all possible results, as I know for a fact that there is
> > a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
> > and a (different) /usr/bin/exabgp-healthcheck file
> > (which is why I prompted my query, as I expect
> > there might be others (I plan to fix exabgp)).
>
> Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp.
> Either a bug or I'm doing something wrong.
>
Thanks for testing DNF5. I notified DNF5 maintainers
.
-- Petr
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 8, 2024 at 9:43 PM Zbigniew Jędrzejewski-Szmek wrote: > Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp. > Either a bug or I'm doing something wrong. And while I can hope that exabgp might be the singleton case, I really don't think you, or I, or other packagers (or FESCo), want to be surprised as to the potential impacts. Thanks for being willing to look further. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 08, 2024 at 03:26:45PM +, Gary Buhrmaster wrote:
> On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sun, Jan 07, 2024 at 03:47:25PM +, Gary Buhrmaster wrote:
> > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote:
> > > >
> > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > > >
> > >
> > > I do not see as part of the plan a process to
> > > go through all Fedora packages and identifying
> > > binaries in /usr/bin that have the same name
> > > as a binary in /usr/sbin (from the same, or
> > > different packages) such that the packager
> > > (or the multiple packages) will need to
> > > coordinate the changes (perhaps by engaging
> > > upstream).
> >
> > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Scope
> > lists 9 packages that was aware of that use usermode.
> >
> > $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
> > '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort |
> > uniq -c | rg -w 2
> >
> > says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> > "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> > need just to be dropped to prevent a FTBFS. I added this list with
> > four packages to the Scope section.
>
> Thanks, but I think the query does not produce
> all possible results, as I know for a fact that there is
> a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
> and a (different) /usr/bin/exabgp-healthcheck file
> (which is why I prompted my query, as I expect
> there might be others (I plan to fix exabgp)).
Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp.
Either a bug or I'm doing something wrong.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Jan 07, 2024 at 03:47:25PM +, Gary Buhrmaster wrote:
> > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote:
> > >
> > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > >
> >
> > I do not see as part of the plan a process to
> > go through all Fedora packages and identifying
> > binaries in /usr/bin that have the same name
> > as a binary in /usr/sbin (from the same, or
> > different packages) such that the packager
> > (or the multiple packages) will need to
> > coordinate the changes (perhaps by engaging
> > upstream).
>
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Scope
> lists 9 packages that was aware of that use usermode.
>
> $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
> '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort | uniq
> -c | rg -w 2
>
> says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> need just to be dropped to prevent a FTBFS. I added this list with
> four packages to the Scope section.
Thanks, but I think the query does not produce
all possible results, as I know for a fact that there is
a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
and a (different) /usr/bin/exabgp-healthcheck file
(which is why I prompted my query, as I expect
there might be others (I plan to fix exabgp)).
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 07, 2024 at 04:58:23AM +0100, Kevin Kofler via devel wrote:
> Kevin Kofler via devel wrote:
> > Aoife Moloney wrote:
> >> == Summary ==
> >> The `/usr/sbin` directory becomes a symlink to `bin`, which means
> >> paths like `/usr/bin/foo` and `/usr/sbin/foo` point to the same place.
> >> `/bin` and `/sbin` are already symlinks to `/usr/bin` and `/usr/sbin`,
> >> so effectively `/bin/foo` and `/sbin/foo` also point to the same
> >> place. `/usr/sbin` will be removed from the default `$PATH`.
> >
> > I am against this because it breaks my kannolo-root-unlocker package:
> > https://svn.calcforge.org/viewvc/kannolo/trunk/packages/kannolo-root-unlocker/kannolo-root-unlocker.spec?revision=270=markup
> >
> > I do not want to patch/overwrite the binaries in /usr/bin (because it will
> > make the RPM verify fail, and also historically because it breaks
> > deltarpms, though AIUI we do not support those anymore anyway), so I put
> > the ones patched to accept running as root into /usr/sbin, which is
> > conveniently before /usr/bin in root's PATH. This change breaks that.
> >
> > If this is implemented, I will have to change the kannolo-root-unlocker to
> > patch the binaries in place. But people who have the old version of
> > kannolo- root-unlocker installed may end up with corrupt binaries, because
> > the scriptlets of course do not expect %{_bindir} and %{_sbindir} to be
> > the same or symlinks to the same. (They are different macros for a
> > reason.)
>
> Note that I already thought of using /usr/local/bin, in fact this was my
> first attempt, but that does not work because kdesu does not search in
> /usr/local/bin, and the KDE SIG also refused to fix that.
It really sounds like something to fix in kdesu.
Stripping directories out of $PATH is a not-thought-through security
theater. Essentially, by the time we get to kdesu, the system already
went through the full boot processes, including the whole graphical
session, so if there's an attacker who managed to put a rogue binary
in /usr/local/bin or /usr/local/sbin which are in the system $PATH,
the game is long over.
(Or in other words, if you can put a rogue binary there and execute
code as root as various points in the boot process, easily and
undectably, why would you wait until a human user happens to execute
kdesu??.)
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 08, 2024 at 10:02:55AM +0200, Panu Matilainen wrote: > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > > > > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > > > > > I agree unifying the *programs* to a single directory makes sense. But I > fail to see anything good come out of bringing all those system daemon > executables into every users path. To clarify: they already *are* in every user's path, see https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Detailed_Description, third para. > This would seem like a good opportunity to move stuff that isn't supposed to > be directly run as part of normal usage under /usr/libexec. I'm sure there > are exceptions but as a rule of thumb, if it has a systemd service file then > it should no longer be in %_sbindir. This was also mentioned by Matthew Miller on discussion.fp.o and I agree, but I think that that's an orthogonal issue. Individual maintainers should evaluate this and do the move if they really think that no one is calling the binary directly. This can be done before or after the proposed change. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 07, 2024 at 03:47:25PM +, Gary Buhrmaster wrote:
> On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> >
>
> I do not see as part of the plan a process to
> go through all Fedora packages and identifying
> binaries in /usr/bin that have the same name
> as a binary in /usr/sbin (from the same, or
> different packages) such that the packager
> (or the multiple packages) will need to
> coordinate the changes (perhaps by engaging
> upstream).
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Scope
lists 9 packages that was aware of that use usermode.
$ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
'%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort | uniq -c
| rg -w 2
says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
"shadow" files in /usr/bin. But those are all symlinks, i.e. they will
need just to be dropped to prevent a FTBFS. I added this list with
four packages to the Scope section.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 08, 2024 at 08:14:49AM +0100, Petr Pisar wrote: > V Thu, Dec 21, 2023 at 10:20:11AM +0100, Vít Ondruch napsal(a): > > > > Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): > > > ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` > > > package). Packages will be updated automatically during the mass > > > rebuild. > > > > > > Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at > > minimum the packaging guidelines be updated? We could probably drop the > > `%_sbindir` automatically in near future. I added a point about adjusting Packaging Guidelines to Scope section in the Change proposal. I don't think we want to drop %_sbindir anytime soon: people use the same specs for older Fedora releases, CentOS, RHEL, OpenSUSE, etc, and undefining %_sbindir would require a lot of updates and make it harder to share the specs. OTOH, keeping the one-line definition of the macro costs nothing. > That or another, I'd like this Change to explicitly state whether packagers > are > supposed to keep using %_sbindir, or to replace it with %_bindir in their spec > files. I added that to Summary now: The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, Dec 21, 2023 at 06:15:13PM +, Richard W.M. Jones wrote: > On Thu, Dec 21, 2023 at 06:58:37PM +0100, Florian Weimer wrote: > > * Aoife Moloney: > > > > > == Detailed Description == > > > The split between `/bin` and `/sbin` is not useful, and also unused. > > > > Programs in /usr/bin have their documentation in section 1 of the > > manual, while programs /usr/sbin are documented in section 8. (In > > general, I deliberately used /usr/bin/ld.so although the manual page was > > already called ld.so(8), without a program of this name existing.) > > > > When moving programs, should we move the manual pages as well? Or at > > least add a link so that that section 1 references work? > > The manual sections have historical meaning: > > https://en.wikipedia.org/wiki/Man_page#Manual_sections > eg. > 1 = general commands > 8 = system administration > > So unless the tools themselves are changing their purpose or are in > the wrong section now, the manual sections should stay the same. This a very good question and a very good answer ;) Thank you both. I added this to point to the Feedback section on the wiki. > > Is there something we can do to help developers on Fedora systems to > > write portable code (not just shell scripts) after this change is rolled > > out? I don't think so. When considering compatiblity of stuff written elsewhere and executed on Fedora, this change if anything increases compatibility, because now both paths are now valid. Going the other way, if somebody were to hardcode the path used on Fedora, that might now be different than than in the past and different than some other distro. But differences in paths already existed (the proposal has a list), so this method wasn't reliable anyway. I think the correct solution is not specify fixed paths at all, and just let $PATH do its job. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin I agree unifying the *programs* to a single directory makes sense. But I fail to see anything good come out of bringing all those system daemon executables into every users path. This would seem like a good opportunity to move stuff that isn't supposed to be directly run as part of normal usage under /usr/libexec. I'm sure there are exceptions but as a rule of thumb, if it has a systemd service file then it should no longer be in %_sbindir. - Panu - -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
V Thu, Dec 21, 2023 at 10:20:11AM +0100, Vít Ondruch napsal(a): > > Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): > > ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` > > package). Packages will be updated automatically during the mass > > rebuild. > > > Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at > minimum the packaging guidelines be updated? We could probably drop the > `%_sbindir` automatically in near future. > That or another, I'd like this Change to explicitly state whether packagers are supposed to keep using %_sbindir, or to replace it with %_bindir in their spec files. -- Petr signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > I do not see as part of the plan a process to go through all Fedora packages and identifying binaries in /usr/bin that have the same name as a binary in /usr/sbin (from the same, or different packages) such that the packager (or the multiple packages) will need to coordinate the changes (perhaps by engaging upstream). I agree that there should be few, but identifying impacts in advance provides for a better decision process, and minimizes the last minute work that packagers need to do (they will have a longer warning and preparation time). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Kevin Kofler via devel wrote:
> Aoife Moloney wrote:
>> == Summary ==
>> The `/usr/sbin` directory becomes a symlink to `bin`, which means
>> paths like `/usr/bin/foo` and `/usr/sbin/foo` point to the same place.
>> `/bin` and `/sbin` are already symlinks to `/usr/bin` and `/usr/sbin`,
>> so effectively `/bin/foo` and `/sbin/foo` also point to the same
>> place. `/usr/sbin` will be removed from the default `$PATH`.
>
> I am against this because it breaks my kannolo-root-unlocker package:
> https://svn.calcforge.org/viewvc/kannolo/trunk/packages/kannolo-root-unlocker/kannolo-root-unlocker.spec?revision=270=markup
>
> I do not want to patch/overwrite the binaries in /usr/bin (because it will
> make the RPM verify fail, and also historically because it breaks
> deltarpms, though AIUI we do not support those anymore anyway), so I put
> the ones patched to accept running as root into /usr/sbin, which is
> conveniently before /usr/bin in root's PATH. This change breaks that.
>
> If this is implemented, I will have to change the kannolo-root-unlocker to
> patch the binaries in place. But people who have the old version of
> kannolo- root-unlocker installed may end up with corrupt binaries, because
> the scriptlets of course do not expect %{_bindir} and %{_sbindir} to be
> the same or symlinks to the same. (They are different macros for a
> reason.)
Note that I already thought of using /usr/local/bin, in fact this was my
first attempt, but that does not work because kdesu does not search in
/usr/local/bin, and the KDE SIG also refused to fix that.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Aoife Moloney wrote:
> == Summary ==
> The `/usr/sbin` directory becomes a symlink to `bin`, which means
> paths like `/usr/bin/foo` and `/usr/sbin/foo` point to the same place.
> `/bin` and `/sbin` are already symlinks to `/usr/bin` and `/usr/sbin`,
> so effectively `/bin/foo` and `/sbin/foo` also point to the same
> place. `/usr/sbin` will be removed from the default `$PATH`.
I am against this because it breaks my kannolo-root-unlocker package:
https://svn.calcforge.org/viewvc/kannolo/trunk/packages/kannolo-root-unlocker/kannolo-root-unlocker.spec?revision=270=markup
I do not want to patch/overwrite the binaries in /usr/bin (because it will
make the RPM verify fail, and also historically because it breaks deltarpms,
though AIUI we do not support those anymore anyway), so I put the ones
patched to accept running as root into /usr/sbin, which is conveniently
before /usr/bin in root's PATH. This change breaks that.
If this is implemented, I will have to change the kannolo-root-unlocker to
patch the binaries in place. But people who have the old version of kannolo-
root-unlocker installed may end up with corrupt binaries, because the
scriptlets of course do not expect %{_bindir} and %{_sbindir} to be the same
or symlinks to the same. (They are different macros for a reason.)
(I wish I would not have to patch binaries at all, but the KDE SIG refuses
to carry patches removing those broken checks from the KDE programs.)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, Dec 21, 2023 at 06:58:37PM +0100, Florian Weimer wrote: > * Aoife Moloney: > > > == Detailed Description == > > The split between `/bin` and `/sbin` is not useful, and also unused. > > Programs in /usr/bin have their documentation in section 1 of the > manual, while programs /usr/sbin are documented in section 8. (In > general, I deliberately used /usr/bin/ld.so although the manual page was > already called ld.so(8), without a program of this name existing.) > > When moving programs, should we move the manual pages as well? Or at > least add a link so that that section 1 references work? The manual sections have historical meaning: https://en.wikipedia.org/wiki/Man_page#Manual_sections eg. 1 = general commands 8 = system administration So unless the tools themselves are changing their purpose or are in the wrong section now, the manual sections should stay the same. Rich. > Is there something we can do to help developers on Fedora systems to > write portable code (not just shell scripts) after this change is rolled > out? > > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
* Aoife Moloney: > == Detailed Description == > The split between `/bin` and `/sbin` is not useful, and also unused. Programs in /usr/bin have their documentation in section 1 of the manual, while programs /usr/sbin are documented in section 8. (In general, I deliberately used /usr/bin/ld.so although the manual page was already called ld.so(8), without a program of this name existing.) When moving programs, should we move the manual pages as well? Or at least add a link so that that section 1 references work? Is there something we can do to help developers on Fedora systems to write portable code (not just shell scripts) after this change is rolled out? Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Dne 21. 12. 23 v 10:20 Vít Ondruch napsal(a): Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` package). Packages will be updated automatically during the mass rebuild. Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at minimum the packaging guidelines be updated? We could probably drop the `%_sbindir` automatically in near future. Of course even dropping the directories instead of linking them would be nice ... Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` package). Packages will be updated automatically during the mass rebuild. Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at minimum the packaging guidelines be updated? We could probably drop the `%_sbindir` automatically in near future. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 2:55 PM Aoife Moloney wrote: > > ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` > package). Packages will be updated automatically during the mass > rebuild. This should probably be set in redhat-rpm-config instead of modifying the core rpm package. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
