[gobolinux-users] Minor hierarchy design overhaul - Occam's razor

[Michael Homer]

On 3/19/07, molfar <molfar.ua at gmail.com> wrote:
> On 3/17/07, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
>
> > The reason it's in /S/K/Boot, I imagine, is so you could have it on a
> > separate partition. A symlink would be nice I guess. In the
> > separate-partition case it would probably be a dead link, though,
> > since you wouldn't have Boot mounted once the system was up.
> That occurred to me either, however this goes against distro's logic (why
> there would be need for having a boot folder on another partition if we are
> doing away with rescue booting at all - we have livecds, right?). Anyway,
> you could have the whole /System folder on another partition. Again, if main
> partition with /Programs on it gets corrupted it would be impossible to
> rescue boot from /System/Kernel/Boot partition since the shell and Bin+Core
> utils reside on corrupted partition - if i get everything correct. Thus
> there is no good reason for not moving " menu.lst" to /System/Settings or at
> least having a symlink for it.
You could also have one boot partition shared between multiple
distributions. I agree that it's not really necessary to lay things
out like that, but there is a legitimate use case for it, so I don't
see much reason to change it.
> > I don't think man.conf is intended to be edited, although I'll defer
> > to somebody who knows more about it.
> Why not? As I gathered it is possible to specify a PATH in it so you can
> have man pages relocated to any place needed. That could possibly resolve
> one of my next issues (about having specifical and rather messed up
> /System/Links/Manuals folder).
You can specify that path, yes, but since it's /S/L/M you don't need
to. You could also have $PATH=/Programs/*/Current/bin, but you don't,
because then the search time becomes prohibitive. Same reason here -
it just takes too long to run things if you don't bring them together.

An FHS system would have a small number of manual directories,
corresponding to the POSIX categories, but that doesn't scale into the
hundreds you'd have in /Programs.

As for man.conf, it probably is a bug (upstream) that it gets put in
/lib. That said, it's autogenerated by configure and so you probably
shouldn't edit it in the general course of things. You could raise the
issue upstream and see what they have to say, maybe submit a patch.
>
> > `rmdir /Depot && problem=solved`. Having a standard name for it
> > probably has benefits, although I don't much use it myself (it's
> > mostly symlinks to areas of other filesystems).
> I know how to solve this problem but we are talking about overall design
> improvement. Thus, why have it in the first place? The philosophical
> principle called "Occam's razor" says: "Don't multiply the entities"
> meaning, in our case, if something can be done with minimal effort - then do
> not overdo it. Do not create redundancies. If /Depot folder is not necessary
> for the system then don't force it. "Encouraging" users to smth. is not a
> solid argument.
Because having a single fixed name is useful and convenient. It's not
mandatory and disadvantages you in no way for it to be present, and
it's deletable and renamable. Although it wouldn't matter much if it
weren't there, there's no real benefit in doing so either. There could
be an installer option I suppose, but that seems like overkill.

I'd rather create it and let people delete it than force them to make
it themselves, myself. It just seems more useful that way. Occam's
Razor really isn't relevant to this scenario, we're not trying to
explain anything.
> > Shared needs to be combined so that everybody looks in the same place.
> > Otherwise it wouldn't be "shared", would it? Many applications want
> > files from other packages.
> Here (
> http://gobolinux.org/doc/wsl2002/gobolinux_wsl2002_english/node4.html)
> Hisham pointed out why global ../Shared folder is not needed. Did I miss
> something since then?
That is obsolete, i.e., it's obviously not the case that "we [opt] not
to have a /System/Links/Shared directory". You did miss some
developments in the last five years.

Different programs' files do have a relation between them - take a
look at pkgconfig and virtually any of the toolkits. It's not always
necessary, but it created a mess of problems and special cases. I
don't know if the old gobo-l archives are still around, but you could
give them a search to see the discussions that took place then. The
executive summary is that yes, a shared Shared directory is necessary.
It was resisted for a long time.
> > I really have no view one way or another, but I really don't see the
> > point in optimising for a case that never occurs - when are you ever
> > going to access /S/L/* directly? They exist only to collect everything
> > in one place to be used in the various PATH variables and such.
> > I'm not sure I understood the part about eliminating the logical
> > inconsistency; could you go into that a little more?
> What I meant about logical inconsistency is that, however, /System/Settings
> was intended to contain only links to relevant programs' folders and reside
> under /System/Links/Settings it provided for some complications (
> http://gobo.kundor.org/wiki/Files_that_cannot_be_symlinks)
> and ruined the design idea somehow. Thus, a newbie user like myself has to
> wonder, why then have a special ../Links definition if overall homogeneity
> is flawed? Why not deprecate it completely and move relevant folders one way
> up as I proposed earlier? That would make everything more logical, since not
> only ../Settings contains files other than symlinks. ../Environment has them
> either, as well as ../Manuals, ../Shared - maybe smth else - haven't looked
> at it deeply.
Because it would make a mess in /System. As well, you edit files in
/S/S, but you shouldn't ever have to touch /S/L/* unless you're
developing, only the items in /Programs. /S/L exists to go in path
variables, it could just as well be GoboHidden.
> > Also no view. I have a slight dislike of shifting basically everything
> > to reside under /System, though. "/System/Files" is a little
> > misleading as well. Especially if you've moved everything from /S/L/L
> > into there as well.
> What I meant about /Files being orphaned is that it contains mostly files
> that are part of the system and used by it. However, the position of the
> folder means that it has somewhat higher structural value than other similar
> things. The overall filesystem hierarchy logic implies that folders under
> "/" should be distinctively different and NOT be of the same semantical
> value as their own subfolders. Thus the distinction between /Users,
> /Programs, /System and /Mount is logical, whether the distinction between
> those folders and /Files isn't obvious since /Files contain something that
> is part of the system and should reside under /System tree.
> A more visual example would be Windows OS (we all are proficient with it to
> the most extent). All fonts, wallpapers and other files that are no part of
> any program but are used by the system are stored under *:\Windows and
> sometimes even under *:\Windows\System(32) folder, thus retaining the
> overall logic of it.
Surely items in /Files are closer to application files than system
files? They go in /Files because fonts, etc, are used by multiple
programs, and others like aren't distributed with the main packages.
/Files might not be the clearest name, but it's a high-level summary
of the contents. They certainly don't belong in /System in any way.
Why do MPlayer codecs belong alongside the kernel directory?

Putting everything under /System like you want is pretty ugly. There's
absolutely no reason to enter /S/L, ever, so tucking them away
somewhere out of the way is a good idea. Fonts and codecs really don't
belong under /System alongside actual system things. I do see a case
for adding a symlink to menu.lst, although fairly low-priority. It
presents some tricky aspects (what if grub isn't installed?).

So in summary, I don't think there's any need to futz with the
filesystem layout. But keep the comments up, bring everybody around to
your way of thinking.
-Michael