[haiku-development] Re: Haiku package management system implementation (was: Haiku package manager)
- From: David Flemström <david.flemstrom@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 7 Feb 2010 11:31:40 +0100
So basically, you find signalling hooks unnecessary. Then we'll strike those
from the list. There's plenty of reason to give an application package the
ability to add itself to the PATH once installed, though, or to export
libraries to other applications, etc. You've once again just eliminated one
single example I made.
On the porting of apps: You know as well as I that Qt now runs on Haiku and
will allow for a myriad of applications to be ported. Whether this is what
you want is not important; the ports will happen anyway, and it might be a
good idea to create a decent package manager, if not to prevent such ports,
then at least to make them behave well in the Haiku ecosystem, and to
prevent a distro from being created that specializes itself in providing
ported apps for the reason that the main Haiku distribution seemingly
doesn't care about them.
Also, I never said that if a package depends on a .so, that only that .so
would be extracted, somehow. What I said was that packages would depend on
files to make the coupling between packages looser, so if someone wants to,
say, replace the system's icon theme, s/he can simply do so by exchanging
one package without breaking any dependencies, since the same icon files
will be available. Or, if a developer wants to use debug libraries to debug
his/her applications, it should be possible to do so without screwing up the
system.
This method of resolving dependencies is at least as fast as normal named
dependency resolution; the sole difference is that packages are called by
their contents rather than by their names. It does not slow down dependency
resolution at all, but actually speeds it up since things such as version
checks (the newest package is simply always chosen), file collision checks
(packages have their own isolated folders and cannot overwrite one another,
ever) etc. can be skipped completely, and half of the dependency path (e.g.
"lib/libc.so" can be split up in key: "lib" and subkey: "libc.so" and be
hashed accordingly) can be used as a table lookup to essentially reduce the
search time of the dependency by an order of magnitude. There's no doubt
that this way of discovering dependencies would be faster than the current
proposal with named dependencies. How much experience do you actually have
with search algorithms?
On Sun, Feb 7, 2010 at 5:15 AM, Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> The idea
> behind the package filesystem in its current form was that the
> individual parts of the package never really wind up being unpacked
> into the actual on-disk filesystem but instead wind up being exposed
> via the VFS. Thus uninstalling a package quite literally doesn't
> require more than removing the package file itself since the
> constituent parts never got littered all over the drive in the first
> place.
Exactly, and how is the system I propose different in this regard? The
system embraces packagefs completely. I suggest that you read through what
I've written more thoroughly.
It seems like I'm not being taken seriously for some reason, and attempts
are being made to simply dismiss what I've written.
Cheers,
David Flemström
Other related posts:
