Subject: Re: Usefulness of pkgviews vs pkg_hack
To: Rhialto <rhialto@azenomei.knuffel.net>
From: Johnny C. Lam <jlam@NetBSD.org>
List: tech-pkg
Date: 09/30/2004 20:55:51
On Thu, Sep 30, 2004 at 10:06:14PM +0200, Rhialto wrote:
> When I reinstalled my laptop with a 2.0_BETA snapshot, I decided to use
> pkgviews, so that I can avoid the package upgrade hell whenever I first
> update my pkgsrc tree and then later decide to install some package that
> requires newer versions of packages that I already have. I used to use
> pkg_hack, which handled this most of the time, but it has a few problems
> and occasionally it fails and you have to fix things "by hand".
> 
> So, I recently updated pkgsrc, and now I wanted to install
> graphics/gqview. And I'm still stuck.
> 
> gqview wanted a newer version of atk, so it built atk-1.8.0. When
> installing, somewhere in the output it apparently said that it could not
> add it to the default view and therefore didn't do that. Okay, fair
> enough. I would perhaps have wanted that it replaced the old version
> with the newer one, but ok.
> 
> It builds and installs one or two more things too, same thing.
> 
> Then when it gets back to building gqview, it says that atk-1.8.0 is not
> installed, and attempts to re-install it which obviously fails.
> 
> Why should it say that atk-1.8.0 is not installed? It /is/ installed,
> after all. Just not in the default view. But it doesn't even need the
> files in the default view, because buildlink3 will use the depoted
> files: ldd clearly shows, for instance, that the shared libraries that
> are used are from /usr/pkg/packages/..../lib, not /usr/pkg/lib[1]. And
> .buildlink/include likewise links to the depoted files.

The problem is that graphics/gqview doesn't support pkgviews installation.
Since it is an "overwrite" package, it only looks for its dependencies
in the default view.

> So, I tried to replace the old atk in the default view by the new one.
> Unfortunately this could not be done: `pkg_view delete atk-1.6.1'
> reported that "atk-1.6.1 is required by other packages", listed a bunch
> of them, and did nothing. And there is not even a "force" option. 
> 
> But these packages do /not/ depend on the default view of atk! They
> depend on the depoted files! I can see no reason why the old atk, or any
> other random package, could not be deleted from default view, since no
> other package depends on the default view due to the way packages are
> linked.

AFAIR, pkg_view won't let you delete atk-1.6.1 from the default view
if there are _overwrite_ packages that depend on it (the atk instance
in the default view).

> I suppose I could create a new view for thew new atk. But I suspect that
> I then have to add just about every package that I have to this view
> too, so that gqview can use them, or whatever package I'd like to
> install next. And I'd have to add it to everyone's $PATH. And I'd have
> to create yet another view the next time I upgrade pkgsrc. So that
> doesn't sound like a scalable solution.

No, this solution won't work.  The root problem is trying to mix
pkgviews and "overwrite" packages, which causes problems exactly as
you've experienced.  You basically lose the advantage of pkgviews for
every package dependency chain that includes "overwrite" packages.

> It looks to me that the best way to fix this problem, is to fix the way
> the pkg build procedure checks for installed packages. Perhaps the
> actual building will even already work after that...

The limitations are mostly due to limitations in the pkg_install tools
themselves, and without fixing those inherent limitations, it will
not be possible to have an "overwrite" package freely depend on a
pkgviews package in the way that you envision.  This is a largish
project that I hope to tackle early next year.  In the meantime,
pkgviews does remain an _experimental_ feature of pkgsrc and is off
by default.  However, this is good feedback as it lets me know that
what I suspected was a deficiency in the way pkgviews in implemented
in pkgsrc is actually causing real problems for users.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>