You are not logged in.
I'd been getting used to having my DE stuff in /opt. Then, all of a sudden, Xfce is in /usr. Not that I mind one way or another, but it did throw me for a loop:
As soon as I installed and started x, my whole Xfce panel setup disappeared. I'm using:
exec xfce4-sessionXfce loaded without any panels. The Settings > Panel Manager wouldn't even start.
I created a new user and copied my .xinitrc to the new /home/user, then started x. This time Xfce ran great (again). So to make this happen for my user, I backed-up most of the hidden files in my user's home with 'mv' and started x again. So far so good, the default panels and Xfce in all it's glory come up fine.
Then I switched the icon theme to Tango, and spent an hour putting all my panels back the way I like them.
The panels themselves are working fine, but I'm missing icons that I wasn't missing before. For example, the Xfce notes plugin has no icon.
I found all the '.desktop' files for the panel plugins in:
/usr/share/xfce4/panel-pluginsWhy they aren't with /usr/share/applications is beyond me.
Now, after a few hours performing my Xfce rescue, I'm ready to fix things. New icon theme would probably avoid pacman upgrades breaking everything, but that's a lot of work even if using existing icons. Editing the .desktop files is fast, but not at all effective if another pacman upgrade moves their location in the filesystem again (and I'm not sure I should use pacman to block portions of upgrades).
Well, on to the icon theme I guess. If I just copy Tango and create a few more symlinks within it, maybe some of icon names the Xfce .desktop files reference will be found.
Offline
During the upgrade the notice did say to do grep -r /opt ~/.config/xf*
and change the paths. For me that worked fine.
I do wonder why XFCE was moved though. Surely XFCE has just as many right to be in /opt as Gnome and KDE.
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate successful termination of their C programs.
Offline
GNOME will also move to /usr by the weekend, though its upgrade path is much cleaner as what was going on with XFCE. We want to step away from /opt/ for packages that integrate perfectly in the system as every other package that goes into /usr.
Offline
I do wonder why XFCE was moved though. Surely XFCE has just as many right to be in /opt as Gnome and KDE.
Gnome is also going to be moving. (Probably KDE too?)
Good riddance to /opt, I say.
I am a gated community.
Offline
Man, I dunno. Things like java, qt and mozilla probably don't need their own little /opt place, but KDE is pretty self-contained and I think it makes sense to have it there. Hell, my /opt/kde/bin folder contains 540 binaries! Now I don't subscribe to the Apple way of doing things where every tiny thing has its own special folder, I think that that's ugly. However, I think it's best to judge things on a case-by-case basis, rather than just universally apply a rigid policy for where things should live.
OTOH, it wouldn't really be a huge deal for me if KDE moved to /usr. Just voicing my opinion is all!
Offline
I agree with Bralkein. Moving the larger DEs to /usr probably isn't optimal. That said, I really don't thing most people will notice.
Offline
Agree with Bralkein.
Offline
I hope Gnome, and any other DE's being moved /opt -> /usr will be put though testing first...
Offline
The reason things are currently installed to /opt is because they, at one time or another, broke the FHS.
Here's another huge thing: quite a lot of work goes into making sure gnome apps know that gnome is not in /usr (same with KDE, et al). In addition, new users often yell and scream when they need to log out after an initial install to /opt (profile.d scripts).
Offline
I was a bit surprised with that move.
I enjoyed the separation and categorization of the configuration files the most. /etc will grow quite large with this move.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
i agree with stonecrest
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
So will KDE move too?
I would not see that as a good thing, I like the Slackware style of keeping DEs separated, especially KDE.
KDE is huge:
[paolo@laptop ~]$ du -sh /opt/kde/
755M /opt/kde/I think its place is where it is now, and I hope it won't move. I would not worry too much for the logout thing...
Paolo
Last edited by palmaway (2007-04-24 02:24:46)
Offline
And what about KDEmod? Will it remain in /opt or will it be moving as well?
Offline
Good riddance to /opt, I say.
well, not totally, as things like java and openoffice have this kind of hier:
$ ls /opt/java/
COPYRIGHT README_ja.html bin include man
LICENSE README_zh_CN.html db jre sample
README.html THIRDPARTYLICENSEREADME.txt demo lib$ ls /opt/openoffice/
LICENSE README.html licenses readmes
LICENSE.html THIRDPARTYLICENSEREADME.html presets share
README help program$ ls /opt/eclipse/
about.html eclipse.ini icon.xpm plugins
configuration epl-v10.html libcairo-swt.so startup.jar
eclipse features notice.htmlso really, I don't think they can integrate with FHS without some shitty workaround (see how gentoo installs eclipse in /usr, roughly they just drop it in /usr/lib/eclipse3.2 and symlink binary to /usr/bin). and I think /opt is really the place for this kind of things.
The reason things are currently installed to /opt is because they, at one time or another, broke the FHS.
Here's another huge thing: quite a lot of work goes into making sure gnome apps know that gnome is not in /usr (same with KDE, et al). In addition, new users often yell and scream when they need to log out after an initial install to /opt (profile.d scripts).
as a software dev, I always had that feeling of out-of-place weirdness about gnome/xfce/kde in /opt, but thought 'hey, that's just me'. now I get it: that implies more dev work, and more work always implies more potential issues. so dev-wise, it's wrong.
plus now, all things being in /etc it makes it a snap to backup config files.
what's more, I don't get how the fact that an app is called 'self-contained' changes anything. it's not like we're on a mac or windows and you copy it to some other directory or computer and expect it to work... as for /etc being crowded, the move really didn't add much to it...
and really, I like FHS, where files are separated by their role, not their belonging app.
To know recursion, you must first know recursion.
Offline
When I project has many, many binaries and libs I like to see what they all are by easily navigating the file-system. I don't see what FHS compliance will gain arch.
I don't care that much though, and if the maintainers come into a lot of problems redirecting all the gnome apps to /opt then go for it.
Offline