Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. It makes no sense to ever have that, and the rest of the world realized that long ago. libexec is from the GNU Coding Standards, which a lot of Linux-isms come from: http://www.gnu.org/prep/standards/standards.html The rationale was always clear to me: libexec is for storing executable programs to be run by other programs rather than directly by users. *Even* GNU violates this standard with the installation of /usr/lib/gcc (among other things). The FSSTND, FHS, and LSB never made mention of libexec. They neither forbid it nor explicitly required it, so it's like every other made up standard that came along. No one really cared enough to stop it because it didn't matter. I think the annoying thing is if you're typing out a path that includes /usr/lib, you can't easily hit TAB to get in to lib. And that's worth fixing. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
2014-05-06 16:06 GMT+02:00 David Cantrell dcantr...@redhat.com:
I think the annoying thing is if you're typing out a path that includes
/usr/lib, you can't easily hit TAB to get in to lib. And that's worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
2) Changing the file system hierarchy and repackaging dozens of hundreds of
packages to make tab completion, let alone tab completion for files that
users shouldn't ordinarily explicitly refer to, easier, is *not* worth
doing.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
2014-05-06 16:06 GMT+02:00 David Cantrell [1]dcantr...@redhat.com:
I think the annoying thing is if you're typing out a path that
includes
/usr/lib, you can't easily hit TAB to get in to lib. Â And that's
worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
Yeah, that's true. The system in front of me is apparently still 32-bit.
2) Changing the file system hierarchy and repackaging dozens of
hundreds of packages to make tab completion, let alone tab completion
for files that users shouldn't ordinarily explicitly refer to, easier,
is not worth doing.
I agree with this. We're talking about janitorial work here and just
generating a lot of change. I'm not opposed to it if we were just something
we said, hey, they next time you update your package, can you move these
files and then eventually libexec would just empty out. Or not, I
really have no strong opinions either way.
--
David Cantrell dcantr...@redhat.com
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 05/06/2014 12:25 AM, Toshio Kuratomi wrote:
snip
%{_libexecdir} and %{_libdir}/$pkg are both valid in the packaging
guidelines.
Yep, and both valid variants differ from what other distros use. Debian
uses /usr/lib/$pkg for @libexecdir@.
snip
If upstream is using the autotools you should just use @pkglibexecdir@ or
@libexecdir@. Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.
I agree with you here. As long as the helpers are only used internally,
it's indeed very simple. It doesn't matter what it exactly expands to:
the app can always find its own files since it can easily keep track how
it was configured.
But there is another class of packages that provide system wide
services. Those packages install system wide helpers and expect _other_
programs to run these.
At that point, the location of /usr/libexec/ vs /usr/lib/$pkg/ vs
/usr/$lib/$pkg becomes the interface that other programs are supposed to
use. And when those differ between different distros, it becomes
difficult for _consumers_ to know where they are installed.
This is why systemd insists on using /usr/lib/systemd on all distros so
that it would be consistent for consumers.
(I wrote a long text here how I ran into this issue having to detect
/usr/libexec/pk-trigger-offline-update (Fedora) vs
/usr/lib/packagekit/pk-trigger-offline-update (Debian), but decided to
delete it since it seemed too specialized.)
If upstream does not use autotools then they may end up having to do
a platform check for helper_dir. But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.
No, I disagree, those are separate issues.
Using /usr/lib/$pkg for helper binaries is no more or no less multilib
compatible than /usr/libexec. Neither one supports parallel installation
of executables.
Relaxing the guidelines would allow those upstreams to write saner code,
and be more compatible across various distributions.
If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with %{_libexecdir} and
%{_libdir}. Most upstreams do not know about or care about multilib. This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg.
Yes, that's a fair point. More options makes it easier for packagers to
mess up in some way. I guess that's also why some people here are
advocating for complete removal of /usr/libexec to reduce the number of
options.
--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
2014-05-06 16:06 GMT+02:00 David Cantrell dcantr...@redhat.com:
I think the annoying thing is if you're typing out a path that includes
/usr/lib, you can't easily hit TAB to get in to lib. And that's worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
Well getting rid of /usr/lib64 and multilib would be another
worthwhile long-term goal. Debian have used a more sensible scheme:
https://wiki.debian.org/Multiarch
For entertainment:
https://bugzilla.redhat.com/show_bug.cgi?id=235752
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 6 May 2014 10:49, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
2014-05-06 16:06 GMT+02:00 David Cantrell dcantr...@redhat.com:
I think the annoying thing is if you're typing out a path that includes
/usr/lib, you can't easily hit TAB to get in to lib. And that's worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
Well getting rid of /usr/lib64 and multilib would be another
worthwhile long-term goal. Debian have used a more sensible scheme:
https://wiki.debian.org/Multiarch
For entertainment:
https://bugzilla.redhat.com/show_bug.cgi?id=235752
I would go through the Debian bug system to find all the issues they have
with their multiarch scheme and certain software. Both 'solutions' cause
issues at time and headaches for packagers to sysadmins to users. Now
whether or not one set of headaches/problems is less painful I don't know..
[I only know this because the one thing my Debian friends ever tell me
that Red Hat got right was with multilib versus multiarch ... of course
they could just be throwing me a bone.]
--
Stephen J Smoogen.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote: On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. /usr/sbin is an invention of Linux. The traditional SysV meaning is /sbin for static binaries, and /bin for and /usr/bin for normal dynamic binaries. Linux then redefine sbin as meaning system binaries, but that's a concept that really doesn't make much sense, as you can see for example by Fedora always placing both /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries in both places... We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: /usr/sbin is an invention of Linux. Hmm, I think Solaris had it, and I know DEC Unix had it. IIRC /sbin came about for static bins, but then also to move config binaries out of /etc. The bins not needed for early system startup moved to /usr/sbin. I don't recall anything in /usr/sbin ever being static. /usr/sbin also got other programs that had been in /usr/lib (such as sendmail) when cleaning up. We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... As I said before, there's still some consolehelper stuff that requires entries in both /usr/bin and /usr/sbin to work. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote: We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... This -- and the current approach of having everything in $PATH -- leads toa really cluttered namespace, making tab completion more frustrating than it needs to be. I'd like to see: * commands which don't work at all as non-root left in usr/sbin and that /removed from the default path; commands which are system commands but work on some level as non-root could go to /usr/bin * and commands which aren't meant to be executed by a human in normal course of operation put somewhere other than /usr/bin -- usr/libexec is kind of quirky but there it is, or else use /usr/sbin for that (and possibly discard the previous notion) This is a lot of shuffling for not necessarily very much gain, but if we're going to have some sort of shuffling, it'd be nice to have one which makes the in-$PATH namespace cleaner. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 11:00 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote: We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... We can't do any cleanup of this form until consolehelper is gone though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 05/05/2014 10:43 AM, Lennart Poettering wrote: On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote: On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. /usr/sbin is an invention of Linux. It existed in *BSD for as long as I used it. The traditional SysV meaning is /sbin for static binaries, and /bin for and /usr/bin for normal dynamic binaries. Linux then redefine sbin as meaning system binaries, but that's a concept that really doesn't make much sense, as you can see for example by Fedora always placing both /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries in both places... We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... Lennart -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote: On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote: On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. /usr/sbin is an invention of Linux. The traditional SysV meaning is /sbin for static binaries, and /bin for and /usr/bin for normal dynamic binaries. Linux then redefine sbin as meaning system binaries, but that's a concept that really doesn't make much sense, as you can see for example by Fedora always placing both /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries in both places... We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... Is there a description somewhere of why /usr/bin instead of ditching it and keeping just /bin ? Ie why the '/usr' prefix ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 05/05/2014 10:43 AM, Lennart Poettering wrote: /usr/sbin is an invention of Linux. Strange that you would claim this. Here's a list of what's in /usr/sbin on NetBSD 1.0 (and there's no overlap between what's in /usr/sbin and any other subdir.) drwxr-xr-x root/wheel 0 1994-10-19 15:16 ./usr/sbin -r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/ac -r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/accton -r-xr-xr-x bin/bin81920 1994-10-19 15:15 ./usr/sbin/amd -r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/amq -r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/arp -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/bad144 -r-xr-xr-x bin/bin40960 1994-10-19 15:15 ./usr/sbin/bootpd -r-xr-xr-x bin/bin32768 1994-10-19 15:15 ./usr/sbin/bootpef -r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/bootpgw -r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/bootptest -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/chat hr-xr-xr-x bin/bin0 1994-10-19 15:15 ./usr/sbin/chown link to ./usr/bin/chgrp -r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/chroot -r-xr-xr-x bin/bin32768 1994-10-19 15:15 ./usr/sbin/cron -r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/dev_mkdb -r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/diskpart -r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/edquota -r-xr-xr-x bin/bin40960 1994-10-19 15:15 ./usr/sbin/fsinfo -r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/gettable -r-xr-xr-x bin/bin24576 1994-10-19 15:15 ./usr/sbin/htable -r-xr-xr-x bin/bin24576 1994-10-19 15:15 ./usr/sbin/inetd -r-xr-sr-x bin/kmem 16384 1994-10-19 15:15 ./usr/sbin/iostat -r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/kvm_mkdb -r-xr-sr-x bin/daemon 28672 1994-10-19 15:15 ./usr/sbin/lpc -r-xr-xr-x bin/bin45056 1994-10-19 15:15 ./usr/sbin/lpd -r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/lptest -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/mailstats -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/makemap -r-xr-xr-x bin/bin28672 1994-10-19 15:16 ./usr/sbin/map-mbone -r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/mk-amd-map -r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/mrinfo -r-xr-xr-x bin/bin36864 1994-10-19 15:16 ./usr/sbin/mrouted -r-xr-xr-x bin/bin28672 1994-10-19 15:16 ./usr/sbin/mtree -r-xr-xr-x bin/bin81920 1994-10-19 15:16 ./usr/sbin/named -r-xr-xr-x bin/bin 93 1994-10-19 15:16 ./usr/sbin/named.reload -r-xr-xr-x bin/bin 136 1994-10-19 15:16 ./usr/sbin/named.restart -r-xr-xr-x bin/bin53248 1994-10-19 15:16 ./usr/sbin/nslookup -r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/nsquery -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/nstest -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/pac -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/portmap -r-sr-xr-x root/bin 65536 1994-10-19 15:16 ./usr/sbin/pppd -r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/pppstats -r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/praliases -r-xr-sr-x bin/kmem 24576 1994-10-19 15:16 ./usr/sbin/pstat -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/pwd_mkdb -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/quot -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/quotaoff hr-xr-xr-x bin/bin0 1994-10-19 15:16 ./usr/sbin/quotaon link to ./usr/sbin/quotaoff -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/rarpd -r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/rbootd -r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/rdate -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/repquota -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/rmt -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/rpc.bootparamd -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/rwhod -r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/sa hr-sr-xr-x root/bin 0 1994-10-19 15:16 ./usr/sbin/sendmail link to ./usr/bin/mailq -r-sr-xr-x root/bin 16384 1994-10-19 15:16 ./usr/sbin/sliplogin -r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/slstats -r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/spray -r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/sysctl -r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/syslogd -r-xr-xr-x bin/bin 126976 1994-10-19 15:16 ./usr/sbin/tcpdump -r-xr-xr-x bin/bin45056 1994-10-19 15:16 ./usr/sbin/timed -r-sr-xr-x root/bin 24576 1994-10-19 15:16 ./usr/sbin/timedc -r-sr-xr-x root/bin 20480 1994-10-19 15:16 ./usr/sbin/traceroute -r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/trpt -r-xr-sr-x
Re: Incorrect order of /usr/bin and /usr/sbin in path
Hi, That's my recollection as well. Heard that confusion about sbin being for superuser before. Jon On 5 May 2014 15:29, Adam Jackson a...@redhat.com wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 05.05.14 11:32, Simo Sorce (s...@redhat.com) wrote: On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote: On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote: On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. /usr/sbin is an invention of Linux. The traditional SysV meaning is /sbin for static binaries, and /bin for and /usr/bin for normal dynamic binaries. Linux then redefine sbin as meaning system binaries, but that's a concept that really doesn't make much sense, as you can see for example by Fedora always placing both /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries in both places... We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... Is there a description somewhere of why /usr/bin instead of ditching it and keeping just /bin ? Ie why the '/usr' prefix ? Since the /usr merge we have the nice property that the entire vendor supplied OS is in /usr, so we can instantiate 100x for 100 containers, with leaving a private /etc and /var for each. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 4:35 PM, Kaleb S. KEITHLEY kkeit...@redhat.com wrote: On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for static not superuser. There's some conceptual overlap, static binaries being there to recover even if your shared libraries are hosed which is normally a superuser kind of operation, but. My recollection is that the s in /sbin and /usr/sbin was more system level management. Things an admin would need but would not usually be needed by an ordinary user. Binaries in /bin and /sbin would have been statically linked to aid in recovering a system in single-user mode when /usr might not be mounted, in the days when disks were so small that /usr might often be a separate disk. Hi, From the hier(7) man page: /bin This directory contains executable programs which are needed in single user mode and to bring the system up or repair it. /sbin Like /bin, this directory holds commands needed to boot the system, but which are usually not executed by normal users. /usr This directory is usually mounted from a separate partition. It should hold only sharable, read-only data, so that it can be mounted by various machines running Linux. You can take a look at the FHS too: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Dridi -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 11:00:05AM -0400, Matthew Miller wrote: On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote: We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions... This -- and the current approach of having everything in $PATH -- leads toa really cluttered namespace, making tab completion more frustrating than it needs to be. I'd like to see: * commands which don't work at all as non-root left in usr/sbin and that /removed from the default path; commands which are system commands but work on some level as non-root could go to /usr/bin * and commands which aren't meant to be executed by a human in normal course of operation put somewhere other than /usr/bin -- usr/libexec is kind of quirky but there it is, or else use /usr/sbin for that (and possibly discard the previous notion) This is a lot of shuffling for not necessarily very much gain, but if we're going to have some sort of shuffling, it'd be nice to have one which makes the in-$PATH namespace cleaner. The full-scope cleanup looks very tempting: https://docs.google.com/presentation/d/1ojgzJOfWB8XaC5kqyrv4IhR9snZKBI77a02R4cj1QM8/edit#slide=id.i0 (Sorry for GDocs link, I don't know other source) -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 05:55:17PM +0200, Tomasz Torcz wrote: The full-scope cleanup looks very tempting: https://docs.google.com/presentation/d/1ojgzJOfWB8XaC5kqyrv4IhR9snZKBI77a02R4cj1QM8/edit#slide=id.i0 That seems to cover a lot of what I'd like to see, yeah, including moving daemons out of the way (and it mentions the consolehelper problem). It's got some other weirdness -- one is misunderstanding the meaning of /usr/share (do not use /usr/share for things which are not shared between packages), but the original intention is kind of absorbed into the multilib proposal anyway. And calling /usr/libexec Fedora-only is of course kind of funny. But, overall, sure, looks cleaner and might be worth working towards, at least where it actually addresses real problems rather than just shuffling for the cleaner look alone. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. It makes no sense to ever have that, and the rest of the world realized that long ago. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes https://lists.fedoraproject.org/pipermail/devel/2012-December/175530.html It's worth knowing the history here. Libexec isn't completely out of the blue -- it comes from GNU. For whatever reason, FHS was resistant to accepting libexec (but somewhat ironically!) the BSDs picked it up, and as I understand it, liked it so much that it's one of the reasons the FHS failed to become more than a Linux standard. http://comments.gmane.org/gmane.linux.lfs.beyond.devel/21616 I could have sworn I had seen something about this on list in the past month, and didn't have time to answer, but I cannot for the life of me find it. Unfortunately, /usr/libexec is not a part of the current FHS, but, is a part of the 3.0 draft 1 (which hopefully will become official someday) https://lists.debian.org/debian-hurd/2011/09/msg00039.html On Wed, Sep 7, 2011 at 11:07 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 16, 2009 at 03:40:05PM +0100, Bastian Blank wrote: Hurd violates the FHS by using /libexec. This name seems to be only used by init and /etc/ttys. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Am 05.05.2014 22:03, schrieb Kay Sievers: On Mon, May 5, 2014 at 9:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences the follwing is *not* any sort of attack your you it's pointless for people maintaining existing machines with existing configurations, systemd-units and so on it's pointless to fix and debug things which are working because reasonable decisions you need to distinct between * reasonable with no impact * reasonable with impact left and right around you * change for the sake of change signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
2014-05-05 22:03 GMT+02:00 Kay Sievers k...@vrfy.org: On Mon, May 5, 2014 at 9:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences. Nah. /usr/libexec is a good place to store system-wide helper binaries without having to worry about the patch changing due to multilib; remember systemd has had to receive an explicit exception[1] for its scheme of storing everything-in /usr/lib/systemd as if it were /opt/systemd, with many of the files located there violating the intent of FHS. Mirek [1] https://fedorahosted.org/fesco/ticket/969 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote: On Mon, May 5, 2014 at 9:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences. It's a practical way to keep helpers out of path and autocomplete without polluting /usr/lib[64] and having to deal with multilib issues, what's pointless about it ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Am 05.05.2014 22:19, schrieb Simo Sorce: On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote: On Mon, May 5, 2014 at 9:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.05.2014 21:45, schrieb Kay Sievers: On Mon, May 5, 2014 at 6:15 PM, Matthew Miller mat...@fedoraproject.org wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. you systemd-guys are really funny - /run was okay and FHS did not matter because it don't get often enough updates and was in your way, libexec is not OK because you don't like itand prefer to fix things which ain't broken - wheter it's part of a proposed FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences. It's a practical way to keep helpers out of path and autocomplete without polluting /usr/lib[64] and having to deal with multilib issues, what's pointless about it? that it was not proposed by systemd-upstream (sorry could not resist) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote: And calling /usr/libexec Fedora-only is of course kind of funny. libexec is Fedora-only, no other major distro used it, not even LSB allowed it. Well, Red Hat Linux, before Fedora. And I believe we got it from BSD (it seems to have made its way to Mac OS X as well); it's in the GNU coding standards, of course... I don't know which was actually first. But the part that's funny is that there's _several other major distros_ right around the corner that also use it. Now, since they're our downstream, they probably would follow suit if we decided to do something different, but that doesn't mean they don't exist. It makes no sense to ever have that, and the rest of the world realized that long ago. It makes _some_ sense -- the rationale for it is in _your_ slides just linked a few posts back -- daemons and other programs meant to be run by other programs rather than by users. That's exactly the point. I think that putting each program into its own subdirectory is probably a better way to solve the same problem in theory, but in practice, libexec does the job fine. As I understand it, the /usr/libexec solution was preferred primarily because it kept /usr/lib just for libraries -- the aesthetic argument, ironically. We certainly don't follow _that_, so if we're going for prettiness, going to /usr/lib/[application] makes sense. But it's also a lot of churn, and it addresses the problem it's aimed at, so the case needs to be stronger than it doesn't make sense to me. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 2014-05-05 at 16:19 -0400, Simo Sorce wrote: It's a practical way to keep helpers out of path and autocomplete without polluting /usr/lib[64] and having to deal with multilib issues, what's pointless about it ? It causes pointless configure and Makefile complications in every single upstream project that wants to install something into that location and has to differentiate between Fedora (/usr/libexec) and the rest of the world (/usr/lib/$pkg). It has ripple-on effects throughout the project - e.g. having to patch the right prefix into desktop files, into service files, etc etc. The fact that multilib gets in the way is an argument against the way we do multilib, not against /usr/lib/$pkg, from my pov. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote: It causes pointless configure and Makefile complications in every single upstream project that wants to install something into that location and has to differentiate between Fedora (/usr/libexec) and the rest of the world (/usr/lib/$pkg). It has ripple-on effects throughout the project - e.g. having to patch the right prefix into desktop files, into service files, etc etc. Now that's a practical reason that I can get behind. But given that we're already here and have done all that, is it valuable to undo? Again, I shrug -- plenty of other stuff to fix, but I think a case could certainly be made. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On 05/05/2014 10:28 PM, Matthew Miller wrote: On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote: It causes pointless configure and Makefile complications in every single upstream project that wants to install something into that location and has to differentiate between Fedora (/usr/libexec) and the rest of the world (/usr/lib/$pkg). It has ripple-on effects throughout the project - e.g. having to patch the right prefix into desktop files, into service files, etc etc. Now that's a practical reason that I can get behind. But given that we're already here and have done all that, is it valuable to undo? Again, I shrug -- plenty of other stuff to fix, but I think a case could certainly be made. I don't think it's valuable to undo it at this point, but rather let applications install into /usr/lib/$pkg/ if they want to. Right now, the Fedora guidelines downright forbid that. I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to /usr/$multilib_directory/$pkg/ -- this ensures that the same directory is available in all distros the same way, and avoids multilib issues with helper binaries. Right now, various upstreams have to ship checks like: if (fedora_based_distro) helper_dir = /usr/libexec else helper_dir = /usr/lib Relaxing the guidelines would allow those upstreams to write saner code, and be more compatible across various distributions. -- Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 10:38:10PM +0200, Kalev Lember wrote:
On 05/05/2014 10:28 PM, Matthew Miller wrote:
On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
It causes pointless configure and Makefile complications in every single
upstream project that wants to install something into that location and
has to differentiate between Fedora (/usr/libexec) and the rest of the
world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
e.g. having to patch the right prefix into desktop files, into service
files, etc etc.
Note that when I first read this, I assumed you meant %{_libexecdir} and
%{_libdir}/$pkg which would be untrue. After reading kalev's message, I'm
guessing that you mean %{_libexecdir} and %{_prefix}/lib/$pkg. This could
also be stated as %{_libdir}/$pkg vs %{_prefix}/lib/$pkg... %{_libexecdir}
and %{_libdir}/$pkg are both valid in the packaging guidelines.
Now that's a practical reason that I can get behind. But given that we're
already here and have done all that, is it valuable to undo? Again, I shrug
-- plenty of other stuff to fix, but I think a case could certainly be made.
I don't think it's valuable to undo it at this point, but rather let
applications install into /usr/lib/$pkg/ if they want to. Right now, the
Fedora guidelines downright forbid that.
I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to
/usr/$multilib_directory/$pkg/ -- this ensures that the same directory
is available in all distros the same way, and avoids multilib issues
with helper binaries.
Right now, various upstreams have to ship checks like:
if (fedora_based_distro)
helper_dir = /usr/libexec
else
helper_dir = /usr/lib
If upstream is using the autotools you should just use @pkglibexecdir@ or
@libexecdir@. Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.
If upstream does not use autotools then they may end up having to do
a platform check for helper_dir. But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.
Relaxing the guidelines would allow those upstreams to write saner code,
and be more compatible across various distributions.
If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with %{_libexecdir} and
%{_libdir}. Most upstreams do not know about or care about multilib. This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg. As long as we have multilib we need to
check the usage of these directories and patch in the separation between the
directories when needed. The usage of %{_libdir}/$pkg and %{_libexecdir}
just makes this more apparent.
We've already gotten rid of multilib distinctions for specific ecosystems
within Fedora so they don't have to make checks like this. We could either
expand that to encompass additional specific ecosystems or we could get rid
of multilib altogether.
-Toshio
pgpJ1pDGlvtN4.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote: We really should get rid of the destinction, and make all of /bin, /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again about $PATH orders and namespace collisions.. Arch made exactly this change this last year. [1] Their distro still seems to work. [1] https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Incorrect order of /usr/bin and /usr/sbin in path
Hi, Recently, the value of my PATH variable seems to be messed up: [asinha@ankur-laptop ~]$ echo $PATH /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin /usr/bin is supposed to come before /usr/sbin etc. This makes mock throw an error: mock -r fedora-rawhide-x86_64 rebuild ./python-taskreport-1.2.1-1.fc20.src.rpm ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. Running /usr/bin/mock.. works, of course. I've checked the relevant places, and everything seems to be in order. The EUID of my user is 1000 too, so there isn't a reason that /etc/profile should place the directories incorrectly. Would anyone have an hints on correcting this? There's nothing in my user's .bash_profile or .bashrc that modifies path either. I use byobu with a tmux backend, but I don't think that matters. I opened a separate gnome-terminal without byobu and the EUID is correct there too. [asinha@ankur-laptop ~]$ id asinha uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock) -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug look what binaries are in /usr/sbin and then you know you really don't want in general a bad package override them with place a binary with the same name in /usr/bin Am 04.05.2014 18:11, schrieb Ankur Sinha: Recently, the value of my PATH variable seems to be messed up: [asinha@ankur-laptop ~]$ echo $PATH /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin /usr/bin is supposed to come before /usr/sbin etc. This makes mock throw an error: mock -r fedora-rawhide-x86_64 rebuild ./python-taskreport-1.2.1-1.fc20.src.rpm ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. Running /usr/bin/mock.. works, of course. I've checked the relevant places, and everything seems to be in order. The EUID of my user is 1000 too, so there isn't a reason that /etc/profile should place the directories incorrectly. Would anyone have an hints on correcting this? There's nothing in my user's .bash_profile or .bashrc that modifies path either. I use byobu with a tmux backend, but I don't think that matters. I opened a separate gnome-terminal without byobu and the EUID is correct there too. [asinha@ankur-laptop ~]$ id asinha uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Reindl Harald wrote: no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug Am 04.05.2014 18:11, schrieb Ankur Sinha: /usr/bin is supposed to come before /usr/sbin etc. I don't know of any kind of standard that specifies either. Does Posix specify this for example? Does anyone have a link? -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Am 04.05.2014 18:54, schrieb Björn Persson: Reindl Harald wrote: no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug Am 04.05.2014 18:11, schrieb Ankur Sinha: /usr/bin is supposed to come before /usr/sbin etc. I don't know of any kind of standard that specifies either. Does Posix specify this for example? Does anyone have a link? normally no software should break independent of that order because it finds the binary anyways in the path and it is unlikely in a clean setup that the same binary exists in both however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, 2014-05-05 at 02:11 +1000, Ankur Sinha wrote: Hi, Hi, Recently, the value of my PATH variable seems to be messed up: [asinha@ankur-laptop ~]$ echo $PATH /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin The same. /usr/bin is supposed to come before /usr/sbin etc. This makes mock throw an error: mock -r fedora-rawhide-x86_64 rebuild ./python-taskreport-1.2.1-1.fc20.src.rpm ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. Running /usr/bin/mock.. works, of course. I've checked the relevant places, and everything seems to be in order. The EUID of my user is 1000 too, so there isn't a reason that /etc/profile should place the directories incorrectly. Would anyone have an hints on correcting this? There's nothing in my user's .bash_profile or .bashrc that modifies path either. I use byobu with a tmux backend, but I don't think that matters. I opened a separate gnome-terminal without byobu and the EUID is correct there too. [asinha@ankur-laptop ~]$ id asinha uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock) I've filled bug for this[0] some times ago. [0]https://bugzilla.redhat.com/show_bug.cgi?id=1092612 -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Reindl Harald wrote: Am 04.05.2014 18:54, schrieb Björn Persson: Reindl Harald wrote: no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug Am 04.05.2014 18:11, schrieb Ankur Sinha: /usr/bin is supposed to come before /usr/sbin etc. I don't know of any kind of standard that specifies either. Does Posix specify this for example? Does anyone have a link? normally no software should break independent of that order because it finds the binary anyways in the path and it is unlikely in a clean setup that the same binary exists in both Right, and in the absence of a specified order in PATH it's a bug if anything depends on *any* particular order. however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin The Filesystem Hierarchy Standard says only that the sbin directories are for programs that only system administrators use, and justifies them with a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. The part about not overriding binaries is your own, personal opinion. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Am 04.05.2014 23:51, schrieb Björn Persson: Reindl Harald wrote: Am 04.05.2014 18:54, schrieb Björn Persson: Reindl Harald wrote: no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug Am 04.05.2014 18:11, schrieb Ankur Sinha: /usr/bin is supposed to come before /usr/sbin etc. I don't know of any kind of standard that specifies either. Does Posix specify this for example? Does anyone have a link? normally no software should break independent of that order because it finds the binary anyways in the path and it is unlikely in a clean setup that the same binary exists in both Right, and in the absence of a specified order in PATH it's a bug if anything depends on *any* particular order. however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin The Filesystem Hierarchy Standard says only that the sbin directories are for programs that only system administrators use, and justifies them with a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. The part about not overriding binaries is your own, personal opinion. no, given that /usr/sbin/iptables is clearly a administrative command and so there is no valid reason to seek for iptables in /usr/bin/ nor have it as override is a logical conclusion if you want to override things /usr/local/bin and /usr/local/sbin are your friends - however - back to topic: Incorrect order of /usr/bin and /usr/sbin in path is plain wrong and the PATH /usr/sbin:/usr/bin is in any case correct - period signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Once upon a time, Reindl Harald h.rei...@thelounge.net said: no, given that /usr/sbin/iptables is clearly a administrative command and so there is no valid reason to seek for iptables in /usr/bin/ nor have it as override is a logical conclusion And there's no reason to look in /usr/sbin for a clearly non-administrative command like ls. The non-admin commands will in most cases vastly outnumber the admin commands, so putting /usr/bin first just makes sense from a performance standpoint. Incorrect order of /usr/bin and /usr/sbin in path is plain wrong and the PATH /usr/sbin:/usr/bin is in any case correct - period No, /usr/bin is supposed to be before /usr/sbin, because otherwise you get broken behavior just like the original poster said they had (mock didn't work but /usr/bin/mock did). The reason is that there are some programs (like mock) that have an entry in both directories. The /usr/bin version is a symlink to consolehelper, that grants additional privileges based on where the user is connected (console vs. network). This is long-time Fedora (and Red Hat Linux before that) behavior. I believe consolehelper is being replaced, but that isn't done yet; after that, the PATH order shouldn't matter. To the OP: I'd suggest checking your .bash_profile to see if something has changed the PATH there. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
Reindl Harald wrote: no, in general /usr/sbin is supposed to come before /usr/bin and any software assuming the opposite has a bug my /etc/profile contains: # Path manipulation if [ $EUID = 0 ]; then pathmunge /usr/sbin pathmunge /usr/local/sbin else pathmunge /usr/local/sbin after pathmunge /usr/sbin after fi Which seems to be that sbin gets *appended* for non-root users, for better or worse. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Sun, 2014-05-04 at 14:19 -0400, Ray Strode wrote: This is probably from a recent gdm bug that was fixed upstream by this commit: https://git.gnome.org/browse/gdm/commit/?id=c9bebed8724600aef6c401f21245f7678e45 Thanks Ray. I'll wait for a gdm update and see if that fixes it. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
