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.

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.

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.

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...


[1] This has one big drawback, as far as I can see: in-place upgrade
(for instance for a critical bugfix) is impossible. The replacement
package, even if it is indeed a drop-in replacement but has a different
version number, will reside in a different directory and all existing
packages will keep using the old buggy library. I'm sure there are ways
to cheat, but that does not count.

-Olaf.
-- 
                           -- Ceterum censeo "authored[1]" delendum esse.
___ Olaf 'Rhialto' Seibert -- [1] Ugly English neologism[2].
\X/ rhialto/at/xs4all.nl   -- [2] For lawyers whose English/Latin is below par.