Subject: Re: RFC: Handle shared dirs in pkgviews
To: C=E9sar_Catri=E1n?= C. <ccatrian@eml.cc>
From: Julio M. Merino Vidal <jmmv@menta.net>
List: tech-pkg
Date: 07/09/2004 10:39:41
I think you are not understanding the problem and the way views work, or
what pkgviews can provide in terms of functionality.

Consider that you install gnome with pkgviews.  Everything is symlinked
into /usr/pkg (because it's the default view).  Good.  Now, start gnome.
You won't see any menu entries (well, if it even starts up).  Why?  Because
it's looking for them into a depot directory, like
/usr/pkg/packages/gnome2-panel-<version>/share/applications, and there are
no other files than the ones installed by gnome2-panel there.

Now suppose we patch gnome2-panel (or configure it with "those special
arguments" you say) so that it _always_ searches for files in
/usr/pkg/share/applications.  Ok.  You build and install gnome, start it, a=
nd
everything looks fine.  Well, now _remove_ it from the default view and cre=
ate
a /usr/gnome view which holds all related applications.  Start gnome.  No m=
enu
entries at all.  Why?  Because it's looking in the default view, where
gnome was removed.

There is _no_ way you can fix this during the configuration nor build stage=
s.
Simply because you don't know where the user will create views and what will
be in them (which can perfectly happen after installation of packages).

But with these wrappers, what will happen is the following: when you run a
binary from /usr/gnome/bin/*, it will be configured (at _runtime_) to open
files from /usr/gnome/share/applications.  And it will only see what's in
that view (i.e., even if you have gedit installed, but not symlinked in
that view, it won't appear in the menu).

And I think you are also confusing it with build time problems.  We don't
have such problems, cos as you say, we set multiple environment variables
within pkgsrc, and we use depot directories and the buildlink directory
directly during the build (views have nothing to do here).

Hope it is a bit clearer now.

Cheers


On Fri, 9 Jul 2004 01:54:59 -0400
"C=E9sar Catri=E1n C." <ccatrian@eml.cc> wrote:

> On Wed, 7 Jul 2004 17:44:08 +0200
> "Julio M. Merino Vidal" <jmmv@menta.net> wrote:
>=20
> > Hi all,
> hi =3D)
>=20
> > 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.
>=20
> > 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 directo=
ry, besides of the default view? that can be set by PKG_CONFIG_PATH. pkgcon=
fig after installed must look into the default view, and that falls in ${LO=
CALBASE}/lib/pkgconfig .
>=20
> > 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 install=
ation, right? that is what we've been doing with aclocal, sdl-config ... pa=
tching or seting env variables already made, like in pkgconfig example.
>=20
> > The benefit of this is that you can change the location on the fly.  Th=
at
> > 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 se=
veral versions and the default view will always be available in the default=
 place ...
> The script can be patched (or wrapped,) to point to the default view and =
modified through PKG_CONFIG_PATH when using different version and location =
of .pc files. That is only in the pkgconfig case.
>=20
> > 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 =
the 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.
>=20
> > Comments?
>=20
> yes, and aclocal has its --acdir, sdl-config the --prefix stuff ... and i=
t was said that scripts and binaries as well can deal with --cflags|CFLAGS =
and --ldflags|LDFLAGS if those packages are wanted to be built outside the =
default view. Those flags, as well as PKG_CONFIG_PATH, are better to be use=
d. PKG_VIEWBASE, what other than /usr/pkg, some depot directory?
>=20
> > Anyway,
> > if we use the same variable everywhere, a user can set it in the enviro=
nment
> > and run the binaries directly, if he wants, instead of having to set ma=
ny
> > different variables.
> I don't think that a user will be installing different versions of, ie, g=
nome. And I don't think a sysadmin have many problems setting many differen=
t variables, used at build stage.
>=20
> As last comment, those scripts can be patched after build stage. There ar=
e many situations for every package that does shared dir stuff, and this fi=
x doesn't have to be done only thinking on pkgconfig.
>=20
> I've not seen too much mails about pkgviews lately. More testing, time an=
d comments seem required ... what do you think about it? is your approach t=
he finest to cover the great picture? I can't see the big picture yet. Are =
enough people using pkgviews or they are only using bl3?
>=20
> regards
>=20
> C=E9sar Catri=E1n C.
>=20


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