You are not logged in.
Why don't we just put everything into /usr? The /opt serves no purpose since all apps are installed/removed by pacman and not untar/rm. And where should you install an app that needs both of kde and gnome?? /opt/kde+gnome?
The reasons people are against this are summarized below:
· The standard says "Large software packages must not use a direct subdirectory under the /usr hierarchy": BUT kde and gnome are not large packages (like openoffice), but many small packages, just like the rest of linux. The "GNOME" or "KDE" is just a conceptual name for end-users. Any app or user could use 1% of gnome/kde packages and keep away from the other 99%.
· Puting all files into /usr is slow: There isn't any benchmark to confirm that. And a nearly-complete gnome 2.14 installation contains only about 100-200 files in /opt/gnome/bin/, compared to more than 1000 in /usr/bin. It just can't cause any slow down on modern linux filesystems. (it's 1,100+ not 11,000+)
Offline
BTW which distro started to use the stupid /opt? Slackware??
Offline
"Large software packages must not use a direct subdirectory under the /usr hierarchy." (Filesystem Hierarchy Standard).
Offline
yes i agree with cheer.
this would just be undermining the standard.
http://en.wikipedia.org/wiki/Filesystem … y_standard
and furthermore, there's no need to install under /usr, as most apps that install under /opt add a symlink to /usr/bin ... also it would be a pain to put so many files under /usr unless absolutely necessary..
imagine, changing the owner of several hundred thousand files after each sys upgrade that includes the kernel, or xorg.
The.Revolution.Is.Coming - - To fight, To hunger, To Resist!
Offline
I agree with cheer and noriko and, btw, why putting kde/gnome and so on in /opt instead of /usr does bother you?
To get something done, a committee should consist of no more than three persons, two of them absent.
--
My Github
Offline
I prefer /opt. Much easier to find configuration files this way.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
Who cares! I agree with sweiss though
Offline
When using other distro's I find myself using /opt/ only for program's that do not honour the traditional bin/ etc/ lib/ share/ (etc) hierarchy. These are usually binary only programs that were ported over from Windows + openoffice.
But I don't really care about it the other way around anymore. Meaning that kde/gnome/firefox are free to live in /opt/ but that Enemy Territory will NEVER get a place in /usr/ or even /usr/local/.
Offline
I think the whole opt thing is silly. Dump it. I have to force apps to install there, some even can't, and have to be manually moved, others can't find stuff in there, it's creating a mess. I really HATE the whole /opt thing. Just be sane, throw it in /usr, where software belongs.
@Norico: opt is creating trouble, all the time here. apps creat symlinks? yeah right, no way. try to install a new theme for KDE. Where does it throw it's files? In /usr, where it belongs. And it doesn't work. Same with plugins etcetera. I was so happy when I saw debian doing sane things by putting all apps in /usr instead of deciding to put some apps in /opt and other in /usr...
The large software packages argument is bull. The largest KDE app can't be more than 25 mb, most are a few mb's big... Ok, OO.o is a mess, but well - that's what it is, a mess. It should disappear from the face of the earth anyway, in opt or not...
-=] life sucks deeply [=-
Offline
Errrr, installing a KDE theme will go to /usr ? Definitely wrong. All kde specific things check a KDE prefix and install it in there. So there is no problem, also not with other apps complaining about a lib that might be not there or what you meant.
pkgconfig might help. please keep /opt, ive seen in frugalware the other way, with things in /usr and its just unfreindly to search for things. not to mention a longer wait for searching the directories.
Offline
once upon a time, it was simpler and certainly cleaner to put things in opt as we do, and we didnt have a standard telling us what to do. Time have changed since, and it's quite a monumental and time consuming task to move all of gnome, all of kde, and all of the various programs back to /usr, something that just doesnt seem like it will reap any benefit for all the effort. That's the sole reason why things are in opt. Simple.
Sure, there's the standard -- but because there's a standard, doesnt mean we must follow it. Plenty of people get caught up in the word 'standard' and instagib-flame-kinghit-ko-up-left-right-right-down anyone who speaks against a standard irrelevant of the quality or applicability of the standard.
It's not like most distros actually observe the standard anyway. I havn't seen a single distro having httpd serve out of /srv. The standard itself is out of date and contradictory. Xorg moved from X11R6 to /usr a while back now. Besides, why seperate X into X11R6? what makes it so special that it must be seperated yet kde and gnome cannot?
And is having kde and gnome seperate actually a violation of the standard?
It's no difficult stretch of the mind to consider them "Add-on application software packages" after all, they're not required for a system to run, and nor are they installed by default, they are addons after installation.
If we now look at the /usr section of the FHS, we see that:
/usr is the second major section of the filesystem. /usr is shareable, read-only data ..... Large software packages must not use a direct subdirectory under the /usr hierarchy.
It isnt difficult to consider KDE and GNOME large software packages. Saying they aren't large because they're split, is like calling OOo small if we split it up into each of it's components, libraries and programs. If you do decide to use any particular KDE and GNOME app, there exists something known as dependencies. For kde, you'll get a minimum of 30mb from kdebase, and that's just the tarball, not the extracted size.
The desktops themselves are quite large anyway. pacman -S gnome. I havn't got a clean install on me here, but it's surely a reasonable size to install to get a functioning GNOME desktop, KDE is definitely quite big, with kdebase alone being 30mb.
If you look at the actual standard, it's pretty flexible, and it's definition of /opt's purpose is very lofty. The rationale for it, is that "The use of /opt for add-on software is a well-established practice in the UNIX community"
http://www.pathname.com/fhs/pub/fhs-2.3 … REPACKAGES
And we can take their approach here too, not only is it fine to put kde and gnome in opt as they are addon packages, but we can use their own rationale and say "that's how we've always done it"
By no means do I remotely agree with the standard, but if you can use it to argue for putting them in /usr, you can also use it to argue for putting them in /opt. Either way, it negates this standard because of the ambiguity in this area and doesnt change the sole reason why things are in /opt in arch, which I explained first.
James
Offline
Why don't we just put everything into /usr? The /opt serves no purpose since all apps are installed/removed by pacman and not untar/rm. And where should you install an app that needs both of kde and gnome?? /opt/kde+gnome?
The reasons people are against this are summarized below:
· The standard says "Large software packages must not use a direct subdirectory under the /usr hierarchy": BUT kde and gnome are not large packages (like openoffice), but many small packages, just like the rest of linux. The "GNOME" or "KDE" is just a conceptual name for end-users. Any app or user could use 1% of gnome/kde packages and keep away from the other 99%.· Puting all files into /usr is slow: There isn't any benchmark to confirm that. And a nearly-complete gnome 2.14 installation contains only about 100-200 files in /opt/gnome/bin/, compared to more than 1000 in /usr/bin. It just can't cause any slow down on modern linux filesystems. (it's 1,100+ not 11,000+)
I would like to have these in /usr, especially gnome and XFCE, as these are fully FHS compliant. IMHO packages that aren't fully FHS compliant don't belong to /usr, but to /opt.
About the speed: /opt/ is slower than putting everything in /usr: the /opt/gnome/bin path is added to the PATH variable and all the XDG_DATA_DIR lookups that have to be done are also adding extra work to the packages that look for icons and launchers.
The only reason for putting these things in /opt is simply because they've always been there in archlinux. Moving things to /usr would break something like 500 packages, which I don't want to rebuild to get the /usr move done. Operation-libtool-slay was the biggest operation we did, which was shitty enough to do already, I don't want any operation that becomes larger than this, especially when it's about moving a prefix of a large suite of packages.
Offline
Xfce could be moved without much trouble, I think.
The core itself is less than 20 packages, IIRC, and everything depending on it will have to be recompiled anyway when 4.4 hits the street in a month or so.
Why not then?
Offline
Xfce could be moved without much trouble, I think.
The core itself is less than 20 packages, IIRC, and everything depending on it will have to be recompiled anyway when 4.4 hits the street in a month or so.
Why not then?
I agree. Why not start small?
-=] life sucks deeply [=-
Offline
So there are only pros for moving to /usr ?
What are the problems of moving to it then, ok alot of packages have to change --prefix=/opt to --prefix=/usr , or is there anything else that i forget here?
Offline
Stuff depending on those packages probably has to be recompiled, etc. It would be huge.
Also, though /opt may be slower... How much slower is it? Is the speed difference involved even noticable on an ordinary desktop machine?
(BTW hasn't this discussion happened 5 times or so before? )
Offline
The problem that I have with /opt is that it's quite shitty to handle when something installs stuff over multiple projects.
How would a gnome program look with mono bindings, python bindings, some mozilla plugins and some nice hicolor icon files:
- mozilla plugins go in /opt/mozilla/lib/plugins
- python goes into /usr
- mono goes into /usr now, used to go into /opt/mono
- hicolor icon theme files go into /usr/share/icons/hicolor
- gnome stuff goes in /opt/gnome
It's a mess to rip this package apart on a /opt system. On a 100% /usr system, it's just ./configure; make; make DESTDIR=${startdir}/pkg install.
Offline
I'd be in favor of getting rid of /opt. Only because it creates confusion, especially when users download something like firefox and then find that they can't run 'firefox' right away. Wait, they have to logout/login just so their $PATH can update? This is one of the most common questions I see regarding Arch. And who the heck wants to close down all their programs and logout/in just so they can use that new applications they just downloaded..
(Yes, I know you can source /etc/profile, but that only updates the $PATH for the current terminal.)
I am a gated community.
Offline
Well, you are right about Firefox, but I personally don't want to have all gnome and kde stuff in /usr. Anyway /opt should stay here, it's perfect place for big games which come in one huge binary.
to live is to die
Offline
It's not just firefox, it's also openoffice, acrobat, java, vmware, ...
I am a gated community.
Offline
Speaking of the devil, this just happened..
16:32 Yekrahs| hmm, why doesnt it work when i click firefox (i just
installed using pacman)
16:32 stonecrest| Yekrahs: logout/in, you need to update $PATH
16:32 Yekrahs| and im updating by logging out and back in?
16:32 stonecrest| yes, /etc/profile gets sourced
sigh. it's just plain silly, imho. you can argue that gnome/kde should use /opt, but arch has gone way too far with it.
I am a gated community.
Offline
Hm, and why Arch do this? Why not change and delete /opt?
It's better to correct this now and not later or?
Have you tried to turn it off and on again?
Offline
It's not just firefox, it's also openoffice, acrobat, java, vmware, ...
IMHO openoffice and java can live in /opt (as well as mono could).
It's hard to draw a line between must-be-in-opt, may-be-in-opt-or-in-usr and must-be-in-usr apps.
to live is to die
Offline
Hm, and why Arch do this? Why not change and delete /opt?
It's better to correct this now and not later or?
it's not as simple as copying stuff across and renaming a few things. as JGC said before, it'd be monumental to move, and there isnt any enthusiasm or need to do it now, and this thread won't provoke it (subtle way of saying, forget about it) the differences are minor and livable anyway, they hardly even score a 1 on a scale of 10, with 10 being annoying.
James
Offline
well, moving everything in one go might be way to much work, but imho it'd be good to start small. Firefox 2.0 could go in /usr, KDE 4 could go in /usr, etcetera. Small steps for Archlinux, a big step for cleaning up.
-=] life sucks deeply [=-
Offline