[haiku-development] Re: [haiku-development] /packages, /system/packages, /system/package-links…
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 24 Mar 2014 12:24:19 +0100
On 03/22/2014 06:09 PM, Jonathan Schleifer wrote:
We currently have the following paths:
/packages /system/packages /system/package-links
/boot/home/config/packages
In /system/packages, we have hpkg files. In
/boot/home/config/packages, we have hpkg files. So far, this seems
consistent. But in /packages, we suddenly have package-links, just as
in /system/package-links.
As you may have notice, /packages is a symlink to
/boot/system/package-links.
IMHO this is inconsistent and not what it
is. There are no packages in /packages, just symlinks.
To me, this is quite confusing. Why is /packages suddenly symlinks? I
would expect that of /system/package-links, but not of /packages.
"package-links" is not actually a particularly good name. Yes, it
contains directories with symlinks, but that's only the syntax level. It
actually contains meta information about the currently active packages
(for the current user). In /boot/system the name "packages" was already
taken, so an alternative name was needed. "active-packages" might have
been better, but you know how it goes with naming...
And
why does /system/package-links contains all package links, even those
from /boot/home/config/packages? From a user point of view, this just
makes no sense. Or am I really the only one finding this
inconsistent?
Unless we want to mount another volume exposing just the package links,
the directory has to live in one of the pre-existing packagefs volumes,
i.e. in /boot/system or /boot/home/config. Given that the latter is
somewhat optional and, in the multi-user case, doesn't have a stable
path, the former was the logical location.
Therefore, my proposal would be: Remove /packages and
/system/package-links, instead use /package-links and mount the
virtual filesystem there. That would give the following layout:
Note, that I'm not actually opposed to using another volume for the
package links. It's just additional work to implement that.
/package-links /system/packages /boot/home/config/packages
or, more consistent: /package-links /boot/system/packages
/boot/home/config/packages
With this, the name makes clear what it is and there is no ambiguity.
I do know that this means we need to recompile all packages, thus my
proposal would be to create a /package -> /package-links symlink for
the meantime until all packages have been recompiled. We can still do
this now, but later this will be more troublesome.
I don't find "/packages" a bad name, as it contains meta information
about the active packages. I would find "/package-links" much worse,
because it would be named after a technicality.
If we think "/packages" might confuse the user, we should just hide it
in Tracker. It is an implementation detail the user shouldn't have to
know about anyway.
Oh, and while we're at it: What's the point of having /system ->
/boot/system? Just to save 5 characters at the price of cluttering /?
I do know that there were heavy objections to adding a /usr -> /
symlink for compatibility, but why then a /system -> /boot/system
symlink?
IIRC /system did exist already exist in BeOS. Removing it will likely
break some software. One could argue that such software was broken
anyway, since it should have used finddir, but TBH I don't really see a
reason to unclutter "/" anyway. In fact I often use /system and find its
existence convenient ("/s" + tab instead of "/bo" + tab + "s" + tab).
CU, Ingo
Other related posts:
