Hi all,

This is something I posted a long time ago (back in April, IIRC) as a reply
to a thread about devel/pkgconfig and pkgviews.  But as there was no answer
(neither "oh, looks good" or "bah, that's just stupid"), I'm posting it
again as a new thread, as I think it just got "lost" in the thread.

It's clear that we've got a problem in pkgviews when it comes to using
shared directories from programs.  Picking pkgconfig as an example, the
problem is that this program is configured to look inside its depot
directory for .pc files, which is completely wrong because there won't be
any there (each package has its .pc files inside its depot directory).

A solution is to configure these programs so that they always look for
files inside the default view, thus pkgconfig could always look into
/usr/pkg/lib/pkgconfig.  I think this is the worst solution; a lot of
flexibility is lost.

Another solution, proposed by jlam@, is to make packages install the few
bits that need to be in shared directories into the depot directory of the
main package.  This means that, in the example I've taken, all programs
and libraries could install their .pc files into the depot directory of
pkgconfig.  This solution also has problems: when adding pkgconfig to a
view, you'd be adding a bunch of other unrelated packages into it, thus
loosing flexibility too.  And it also breaks the concept of "a package
per directory", which could be very nice to keep.

The last solution, the one I'm proposing, is the following: make each
package install itself in its own depot directory.  But, for packages
that search for files in shared directories (pkgconfig, in this example),
add a patch that changes the path where files are searched.  Instead of
hardcoding the path value in the binary, the program should check the
value of an env variable (PKG_VIEWBASE) and look for files there.
I.e., pkgconfig could use ${PKG_VIEWBASE}/lib/pkgconfig to search its
files.  (We'd make it fallback to the default view if the variable is
unset).

The benefit of this is that you can change the location on the fly.  That
is, if you have multiple views, you can get any program return the right
results with what's symlinked in the view directory, and just that.  You
get no more and no less files.

For example, one could have a view for kde and another one for gnome.
Even though these two desktops now share some directories (consider that
menu entries from both desktops appear merged), you could completely
separate them with this approach.  Each desktop could search its files in
its own view, and never notice that there is another one installed.

But "hey, you have to set an environment variable to get this working!".
I think we can go with that.  It's a minor problem.  And it can be
worked around using wrapper scripts: we'd have to change linkfarm (or
whatever) so that, instead of creating symlinks for _binaries_ (and
only binaries), it creates little wrapper scripts that 1) set PKG_VIEWBASE
accordingly and 2) run the real binary afterwards.

With this approach, we get: no "main" view (aside from pkgsrc's POV),
real separation between views and "a package per directory".

Keeping in mind that the number of packages using shared directories is
very big, and growing, this should be worth the effort.  And I'm willing
to work on it.

Comments?

-- 
Julio M. Merino Vidal <jmmv@menta.net>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/