As I explained in a previous post, pkgviews enables the installation of each package in its own depot directory. To accomplish this, the package gets configured with a different prefix (for autoconf users, using --prefix flag) for each package.
Now consider a program that uses a directory where other programs can install files. Let's take, for example, XMMS. This package, when installed with pkgviews, will have all of its files under /usr/pkg/packages/xmms-1.2.10; but note that all of the hardcoded paths will also point inside the depot directory. What does this mean? Simply that XMMS will try to load its plugins from its depot directory! And, as the only package that puts files there is XMMS itself, it won't be able to find any extra plugins installed by other packages.
There are several ways to solve and/or workaround this problem. For example, all packages could be patched in a way so that they always look for files in "shared directories" under a fixed view, like /usr/pkg (the default view). The problem of this solution is that you loose a lot of flexibility if you ever want to use multiple views.
Another solution is to make packages install those "special" files into the depot directory of the main package. In the example of XMMS, this means that all packages providing plugins could get installed under XMMS' depot directory. With this approach, you loose the concept of a package per view and you are also forced to add an amount of packages in each view, even if you don't want them.
These two solutions are applied at build time. There is no way you can fix this problem while building the packages. The reason is that views can be created or removed after and before installing packages. So they can't know during the build which views will be available, and in which views they'll be added.
To solve the problem, one has to find a way to change the binary behavior at runtime. But I'll leave this for a further post (probably tomorrow), and let you think about it in the meantime ;-)
