Re: Need for FORCE_PKG_REGISTER to avoid snags when updating packages

[mueller6721%twc.com@localhost]

from Martin Husemann and my previous message:

> mueller6725%twc.com@localhost writes:

> > When installing or updating a package in NetBSD with pkgsrc, or I suppose any OS that might use pkgsrc, the build may be stopped by an earlier version of a dependency.

> > For example,

> > => Creating binary package /BETA1/pkgsrc/lang/ruby24-base/work899.amd64/.packages/ruby24-base-2.4.6.tgz
> > ===> Building binary package for ruby24-base-2.4.6
> > => Creating binary package /usr/packages/All/ruby24-base-2.4.6.tgz
> > ===> Installing binary package of ruby24-base-2.4.6
> > pkg_add: A different version of ruby24-base-2.4.6 is already installed: ruby24-base-2.4.5
> > pkg_add: 1 package addition failed
> > *** Error code 1

> > This is very annoying, even though I can pkg_delete -f (ruby24-base in this case), and then go to the appropriate directory and make install.

> > This is very inefficient compared to just keeping going, as I believe can be dome in FreeBSD ports by including in /etc/make.conf,

> > FORCE_PKG_REGISTER=yes

> > or setting via the command line.

> So what exactly does this setting do?  Why is that ok?

When a package (using FreeBSD ports) does not install because a previous installed version is in the way, FORCE_PKG_REGISTER causes the package to be installed, replacing the older installed version.

> > How can I achieve this effect in pkgsrc where FORCE_PKG_REGISTER is not available?

> I don't know what it does, but here are two suggestions.

>   1) it is undefined behavior to update your source tree and not update
>   all mismatched installed packages and things that depend on them.  So
>   don't do this, or if you do, figure out how to deal with the
>   consequences.  This is why pkg_rr was created.  Yes, it doesn't always
>   succeed, but your other options are a pbulk run and then removing
>   everything and reinstalling, or muddling through.  Manually removing
>   the renamed packages is not that hard, once one stops objecting to the
>   concept.

>   2) What I do when I run into this is:

>     (cd ../../lang/ruby24-base && make replace clean)
    make

>   This mostly works, although is of course technically undefined
>   behavior.   It amounts to on-demand pkg_rr in an odd order.

What I did worked but was inconvenient and not really efficient, looks comparable to your suggestion.

When you say "update your source tree", I assume you mean pkgsrc as opposed to system source typically installed to /usr/src.

But updating system, especially NetBSD-current, can cause some packages to not work right.

Installed packages and dependencies can become mismatched by package removals and renaming in pkgsrc, or by pkg_update gone bad, removing packages and unsuccessful in rebuilding.

So my installed packages were in a mess; still are, but not as severely.

Manually removing packages that are "moved or obsolete" is not always sufficient.

Is there a quick way to set up a pbulk run if I have a list of all desired packages?

I could move /usr/pkg to /usr/pkg-old, /var/db/pkg to /var/db/pkg-old, and /usr/packages to /use/packages-old, put /usr/pkg/sbin ahead of /usr/pkg-old/sbin, and /usr/pkg/bin ahead of /usr/pkg-old/bin in the PATH and still use the old stuff temporarily while rebuilding.

Tom