[haiku-development] Re: packages/assignfs (was: Re: alpha release window ?)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 11 Aug 2009 14:51:22 +0200 CEST
Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> >> 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.
No, it doesn't adhere to the system's standards, and thus, it's broken.
You *have* to use find_directory(), and must not use fixed paths.
> 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.
And that doesn't relieve them from being ported properly. A port
usually involves more than a simple recompilation; sure that makes it
harder to do, but if you want to port a software, you should be serious
about it. Everything else is just a hack.
> > It's also not nice to hide the fact that
> > software is installed locally only.
> There are other ways to make this fact obvious.
Why should those be used when there is a perfectly fine and working
directory hierarchy?
> > "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 :)
assignfs is not ugly by itself, I just don't think it's the right thing
to use for the package manager.
Also, IMO the package manager should just utilize it, not have the
package file system built on top of it.
> >> 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).
AFAICT it's the least error prone way that also keeps the door open for
security patches while keeping the ABI unchanged. Of course it's some
work, but package management is supposed to be some work; the quality
of the package management can only be maintained when someone actually
puts some work into it.
> >> 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
> be added to the application's assign by the package manager.
The latter sounds much better, at least.
In any case, I think another disadvantage of your method is that it
hides information - you can't know what library your application links
against unless the package manager provides that information in another
way.
I find using assignfs this way more complicated and confusing than
using the standard features of the file system, and directory
hierarchy. At least I don't see any reason why this should be this
complicated, or just different to the rest of the system.
Bye,
Axel.
Other related posts:
- » [haiku-development] Re: packages/assignfs (was: Re: alpha release window ?) - Axel Dörfler
