[Midnightbsd-mports] How to prevent the automatic use of cached installed packages with old dependencies?

[Chris Reinhardt]

On Tue, May 20, 2008 at 4:38 PM, Lucas Holt <luke at foolishgames.com> wrote:
>
> On May 19, 2008, at 6:45 PM, Stevan Tiefert wrote:
>> ...
>
>> During the installation of linux-firefox the process tried to use
>> also the cached packages and stopped during the build of linux_base-
>> fc-4 when it wanted to use the rpm-*, gcpio-* and libpopt-*-
>> packages. The error hinted me to a missing libintl.so.6 (but at the
>> same time gettext 0.16.1 with libintl.so.8 was installed) which was
>> in gettext-0.14 (an outdated build-dependency). I had to build these
>> three again and then linux_base-fc-4 was ok. After the first starts
>> of linux-firefox it crashed with coredumps and the error hintet me
>> to a problem with linux-fontconfig which also was a cached installed
>> package with the outdated build-dependency to gettext-0.14. After a
>> rebuild of linux-fontconfig the browser was working how it should.
>>
>> My question is: Which behavior is wrong? Mine or mports :-) ?
>
>
> I've been bitten by this before.  There was a discussion about
> removing cached packages, but I don't remember what the outcome of
> that was.  I typically delete all the packages when I'm doing a big
> update (like KDE or Gnome) to avoid this.  One possible solution is to
> use a tool like portupgrade to update ports depending on a package as
> well.  (it will rebuild them)
>
> In the future, this can be avoided with mport, the tool to update
> packages that ctriv@ is working on.  The other factor is that
> PORTREVISION needs to get bumped more frequently when dependancies are
> updated.  We sometimes forget to do this and it causes a lot of
> problems.

The issue of implied updating when a depend is updated is tricky.
Portupgrade avoids this issue by upgrading up and down the depends
tree, libmport will probably do the same thing (unless research into
the topic provides a more elegant approach).  Luke hit the nail of the
head though, unless PORTREVISIONs are always bumped correctly
(something that _every_ port maintainer gets wrong from time to time)
the ports tree has no way of knowing if a cached package is valid or
not.  We've meandered into the BSD equivalent of
DLL hell with the shared library versions.

In the future this problem will be much better, you may even be able
to `cd /usr/mports; make upgrade` and have it "just work."  The
improved update facilities, along with better tools for port
maintainers should improve the situation.

Meanwhile, cached installs may be a neat idea that doesn't quite work
right.  It's an odd intersection of the package and ports world, and
it often makes things worse rather than better.  Perhaps `make clean`
should delete the package from the package dir as well?
-- 
Chris Reinhardt - chris.reinhardt at gmail.com