Bug 5359 - Summary of FHS violations
|
Bug#:
5359
|
Product: Gentoo Linux
|
Version: 1.3
|
Platform: All
|
|
OS/Version: All
|
Status: RESOLVED
|
Severity: major
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: bug-wranglers@gentoo.org
|
Reported By: vapier@gentoo.org
|
|
Component: Unspecified
|
|
|
URL:
|
|
Summary: Summary of FHS violations
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2002-07-21 17:22 0000
|
Gentoo & FHS
http://www.gentoo.org/ & http://www.pathname.com/fhs/
rather than opening multiple bug reports i thought i would just file this all
under one ... ill add more comments as my box emerges more packages and i can
check out where it installs stuff
Thanks! Most of these look like genuine bugs. CCing Azarah for baselayout
stuff.
I'm confused by the first entry, a "[" binary? We do violate the FHS when it
comes to DJB / daemontools stuff -- it's just too painful for users if
we don't use /service.
Comment #1: /usr/bin/test (part of sh-utils) are there as required. '[' is
provided by bash/sh (where sh is a link to /bin/bash) as required.
Comment #2: It should be /bin/hostname now, but things have changed recently,
so it could be that for our current stage1, it is still /usr/bin/hostname.
Comment #22 should read: Should /usr/bin/test also be installed as /usr/bin/[
as well?
i have no idea wtf a [ binary is ;)
i'm just going by the fact Gentoo has no [ binary ...
as for just symlinking [ to test ... i dont *think* that will work because if
you issue the cmd '[ 1 == 0 ]' then you'll be bassing "1 == 0 ]" to test which
will be incorrect ... although i have no idea ;)
nosferatu bin # ln -s test [
nosferatu bin # [ -f /etc/hosts ] && echo yes
yes
nosferatu bin # [ -f /etc/hostss ] && echo yes
nosferatu bin #
It actually do work :P Do you have access to Redhat/Mandrake/Debian to have
a look ?
./[: /etc/hostss: binary operator expected
nosferatu bin # ./[ -f /etc/hostss && echo yes
nosferatu bin # ./[ -f /etc/hosts && echo yes
yes
nosferatu bin #
Bleah, maybe not. Guess it was bash who override things.
(from a shell server i have access to)
bash-2.05a$ uname -a
FreeBSD Mars.unixrules.net 4.6-STABLE FreeBSD 4.6-STABLE #5: Sat Jul 13
06:54:17 PDT 2002 riko@Mars.unixrules.net:/usr/src/sys/compile/mars i386
bash-2.05a$ ls -ali \[ test
101534 -r-xr-xr-x 2 root wheel 53k Jul 7 23:43 [*
101534 -r-xr-xr-x 2 root wheel 53k Jul 7 23:43 test*
bash-2.05a$ ./\[ -f /etc/hosts ] && echo yes
yes
how about this little hack of a binary ? :)
#include <unistd.h>
int main(int argc, char **argv) {
argv[0][0] = '[';
argv[0][1] = '\0';
execv("/usr/bin/test\0", argv);
execv("/bin/test\0", argv);
return 0;
}
rux0r bin # cd /usr/bin/
rux0r bin # gcc \[.cpp -o \[
rux0r bin # ./\[ -f /etc/hosts ] && echo YES
YES
#4: grub's menu.lst has to be on the boot partition I think. And since our
/boot isn't mounted by default, a symlink from /etc wuoldn't really work, it'd
be broken most of the time. Ideas? #16: I have a bug about on it on my list,
working to fix.
app-text/pinfo-0.6.5_p2-r1 contains a proper fix.
Mandrake 8.2 system:
[spider@m�ndrake spider]$ ls /usr/bin/[ -al
lrwxrwxrwx 1 root root 4 Jul 21 21:19 /usr/bin/[ -> test*
Dan, is it possible to bring qt-docs into FHS compliance?
William, can you check the vmware-workstation compliance, please?
lcd4linux seems to behave fine, though
At first I was baffeled by vmware-workstation putting anything in /share but
looking at the ebuild I see that if any of: $KDE2DIR, $KDE3DIR, $KDEDIR isn't
set it could do that.
could someone point me to info on what the proper use of $KDE*DIR is I'll fix it.
KDE2DIR and KDE3DIR are deprecated, and were never very officially supported.
/usr is now in KDEDIRS. Meaning, that you can (and should) just install files
(menu items etc) in the right place under the /usr main hierarchy and kde will
pick them up.
qt-docs: it's a bug where it puts things into /. Several people have reported
that, both with qt and qt-docs, and it drove me mad for a while because I
couldn't reproduce it. I never did, but people stopped reporting it. Did you
hit this bug, seemant? If so you could be of great help in debugging it :-)
Just look at its src_install, I can't see how things can end in /...
OK, I've fixed the vmware issue. Committed.
closing this bug then, coz I think all the issues are sorted.
note to danarmak: the qt/qt-docs issue never bit me at all.
possibly they tried to install qt-docs without qt installed?
thanks much to SpanKY :)