[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
> 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,
> or setting via the command line.
So what exactly does this setting do? Why is that ok?
> 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.
Main Index |
Thread Index |