3 ms·

Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?

by cbsmith 15y ago

deleted 15y ago
[deleted]
el_presidente 15y ago
Probably because fedora has a six month release cycle and they feel the need to make some kind of revolutionary change on every release. Of course, /bin will never be removed since there are millions of scripts depending on /bin/sh in the wild. So they'll basically end up having to maintain this symlink spaghetti for a long time.
- aangjie 15y ago
  I agree with that symlink spaghetti for a long time comment.. It seems harsh to fedora to say they feel a need for a revolution.. i really don't follow release cycles/linux versions... close enough.. but my upgrade experiences so far(Fedora 8-13 vs Ubuntu 8-11.10) indicate it's ubuntu that feel a need to make revolutionary change.. i.e: to say, i have gone wtf more times searching for some custom setting on ubuntu menu's than fedora's
elehack 15y ago
The feature implementation and details have seen some refinement, so it's much less of a mess in its current state (e.g. the directories are symlinked, not the files): https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove You get wins on packaging (don't need to worry about where to scatter executables, although this doesn't affect many packages), as well as "all software is under /usr", so everything the package manager touches except config file updates is under a single directory. This makes both centralized updates and pre-update snapshotting much more feasible. I'm really looking forward to this feature. With appropriate support from the file system and yum, it seems like it brings us one step closer to truly transactional multi-package system updates/software installations. Yes, some of this was already possible with snapshotting support in a plugin for Yum, but I think the consolidation will likely make implementing such features simpler and more robust.

Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?

by cbsmith 15y ago

Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?

deleted 15y ago

[deleted]

el_presidente 15y ago

Probably because fedora has a six month release cycle and they feel the need to make some kind of revolutionary change on every release. Of course, /bin will never be removed since there are millions of scripts depending on /bin/sh in the wild. So they'll basically end up having to maintain this symlink spaghetti for a long time.

aangjie 15y ago
I agree with that symlink spaghetti for a long time comment.. It seems harsh to fedora to say they feel a need for a revolution.. i really don't follow release cycles/linux versions... close enough.. but my upgrade experiences so far(Fedora 8-13 vs Ubuntu 8-11.10) indicate it's ubuntu that feel a need to make revolutionary change.. i.e: to say, i have gone wtf more times searching for some custom setting on ubuntu menu's than fedora's

elehack 15y ago

The feature implementation and details have seen some refinement, so it's much less of a mess in its current state (e.g. the directories are symlinked, not the files): https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove You get wins on packaging (don't need to worry about where to scatter executables, although this doesn't affect many packages), as well as "all software is under /usr", so everything the package manager touches except config file updates is under a single directory. This makes both centralized updates and pre-update snapshotting much more feasible. I'm really looking forward to this feature. With appropriate support from the file system and yum, it seems like it brings us one step closer to truly transactional multi-package system updates/software installations. Yes, some of this was already possible with snapshotting support in a plugin for Yum, but I think the consolidation will likely make implementing such features simpler and more robust.