[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Need for FORCE_PKG_REGISTER to avoid snags when updating packages
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
> 2) What I do when I run into this is:
> (cd ../../lang/ruby24-base && make replace clean)
> 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.
Main Index |
Thread Index |