[haiku-development] Re: Removing /boot/common

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 07 Oct 2013 17:51:23 +0200

On 10/07/2013 10:51 AM, Axel Dörfler wrote:
  On October 7, 2013 at 2:10 AM Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Sorry, I try again:
1) assume a package that is divided into several packages, where one of them is
installed in system (let's call it A, the other package would be B).
2) you want to install B, but in common.
3) B does not declare a dependency to A but to common-A IOW it declares the need
to find its sister package in the same installation path.
4) common-A shadows A.
5) everything continues to work with the downside that you now have A and
common-A installed.

If I understand you correctly it is already implemented that way. A package can declare another package as its base package. The package manager/daemon then makes sure that the base package of a package is always installed in the same installation location, potentially duplicating the package of a more general location. E.g. if you install gettext in home (or, when it still existed, common), its base package gettext_libintl is copied from system to the target location, thus ending up being installed in both.

Since we will not very likely be able to eliminate all the problematic package dependencies, this solution will stay with us, I suppose. Having a /boot/common doesn't make it necessary -- we'll need it for home anyway -- but it aggravates the problem. While installing something in home is exceptional, installing in common would be the typical case.

That would be a compromise as well, but if this is a rare case, I guess it could
be acceptable.

ATM, it is not rare at all, since it concerns all devel packages.

  Sure. Regarding find_directory(), as we know now, it isn't a
  particularly good API. It failed with both the introduction of the
  non-packaged hierarchies and the removal of /boot/common.

Okay, let's call it the concept of find_directory() then :-)
Have you already thought of an extension to that API?

I suppose for C we would need a function that returns a list of directories. For C++ we could pimp up/wrap BMergedDirectory (headers/private/storage/MergedDirectory.h), adding node monitoring support as well.

CU, Ingo


Other related posts: