Subject: Re: RFC: Handle shared dirs in pkgviews
To: Julio M. Merino Vidal <jmmv@menta.net>
From: =?ISO-8859-1?Q?C=E9sar_Catri=E1n?= C. <ccatrian@eml.cc>
List: tech-pkg
Date: 07/09/2004 01:54:59
On Wed, 7 Jul 2004 17:44:08 +0200
"Julio M. Merino Vidal" <jmmv@menta.net> wrote:

> Hi all,
hi =3D)

> 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).
... and ${LOCALBASE}/lib/pkgconfig of course.

> 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.
flexibility you mean ... pkgconfig looking at every decided depot directory=
, besides of the default view? that can be set by PKG_CONFIG_PATH. pkgconfi=
g after installed must look into the default view, and that falls in ${LOCA=
LBASE}/lib/pkgconfig .

> 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).
well, it is a script, not a binary, so, it is easy to patch after installat=
ion, right? that is what we've been doing with aclocal, sdl-config ... patc=
hing or seting env variables already made, like in pkgconfig example.

> 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.
... ok ... so, .pc files from different packages can be available from seve=
ral versions and the default view will always be available in the default p=
lace ...
The script can be patched (or wrapped,) to point to the default view and mo=
dified through PKG_CONFIG_PATH when using different version and location of=
 .pc files. That is only in the pkgconfig case.

> With this approach, we get: no "main" view (aside from pkgsrc's POV),
> real separation between views and "a package per directory".
preventing packages which are not in the default view putting stuff into th=
e shared directory, where the default view exists?
=20
> 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?

yes, and aclocal has its --acdir, sdl-config the --prefix stuff ... and it =
was said that scripts and binaries as well can deal with --cflags|CFLAGS an=
d --ldflags|LDFLAGS if those packages are wanted to be built outside the de=
fault view. Those flags, as well as PKG_CONFIG_PATH, are better to be used.=
 PKG_VIEWBASE, what other than /usr/pkg, some depot directory?

> Anyway,
> if we use the same variable everywhere, a user can set it in the environm=
ent
> and run the binaries directly, if he wants, instead of having to set many
> different variables.
I don't think that a user will be installing different versions of, ie, gno=
me. And I don't think a sysadmin have many problems setting many different =
variables, used at build stage.

As last comment, those scripts can be patched after build stage. There are =
many situations for every package that does shared dir stuff, and this fix =
doesn't have to be done only thinking on pkgconfig.

I've not seen too much mails about pkgviews lately. More testing, time and =
comments seem required ... what do you think about it? is your approach the=
 finest to cover the great picture? I can't see the big picture yet. Are en=
ough people using pkgviews or they are only using bl3?

regards

C=E9sar Catri=E1n C.