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