[haiku-development] Re: alpha release window ?
- From: Brecht Machiels <brecht@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 11 Aug 2009 14:26:41 +0200
Axel Dörfler wrote:
Hi Brecht,
Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
I wouldn't like to join this into a single directory (for the
user),
and have different views for each user - that would just be like
calling for trouble (as the root user should see them all).
But then you would lose the possibility for users to install software
locally that depend on absolute paths. I know this should be avoided,
but some ports will require that.
If a port requires that, it's broken, as simple as that.
That is your personal definition of broken.
If the path-independence requirement makes it much harder to port some
applications, I don't see it as an absolutely necessary requirement.
They are just ports, after all.
Wherever bundles will be mounted eventually, it will still be possible
to create an assign for a port, say at /assign/whatever-1.0.
I see no major problems in mounting user bundles also under
/boot/common. It shouldn't be hard to provide a mechanism for root to
show all users' bundle mounts.
That's just ugly IMO, and not where this stuff belongs - it's called
"common" for a reason.
Ok, let's not use the path /boot/common then.
It's also not nice to hide the fact that
software is installed locally only.
There are other ways to make this fact obvious.
"root" would need to see all packages, which also means they would all
be installed for root. That doesn't sound like the way to go, either.
I could see some uses for an assignfs, but IMO it's not the right
solution for this particular case.
I'm not saying it is. The way I see it, we are evaluating a number of
different designs for a package management system, and for some of them,
assignfs can be valuable. In case we go for a pkgfs, the assignfs code
can serve as a starting point, if it's not too ugly for your standards :)
On a related note. How do you see Haiku handling multiple versions of
a
library? If all bundles are mounted under /boot/common, they would
need
to have a unique namme (libfoo-1.2.3.so). For an application to use a
particular version, we would need to virtually link a library into
the
app's lib search path, as libfoo.so. I hope you agree we don't want
to
have apps looking for a specific version of a library (libfoo-
1.2.3.so)?
I think that depends on the library in question. Mostly I would think
it's cleaner to have a version number per ABI change (which does not
necessarily reflect the actual version number).
OpenBSD, for example, gives each foreign library their own number per
ABI change which usually differs from what the project itself does. I'm
afraid this is something we might need to do as well, since many
projects do not understand (or care about) binary compatibility.
This is an option yes, but it would be error-prone. A porter could miss
an ABI change. While it would work in most of the cases, I'd prefer the
dynamic dependency solution together with simple port revision
numbering. That way, problems are solved in a distributed manner, which
should be quite fast (it does not require an action by the app/lib porter).
For a non-union-FS approach, each lib would be mounted under it's own
directory (/boot/bundles/libfoo-1.2.3 or similar) and it's lib
directory
(/boot/bundles/libfoo-1.2.3/lib) would simply be added to the app's
lib
search path (based on the bundle's dependency information and which
library bundles are installed).
That would work as well, but will need some interaction between the
runtime_loader and the package manager, which I find a bit clumsy
(someone has to set those search paths when the app is launched).
The app can be started through a script. Or the required libs can simply
added to the application's assign by the package manager.
Brecht
Other related posts:
