Re: Need for FORCE_PKG_REGISTER to avoid snags when updating packages

[Greg Troxel <gdt%lexort.com@localhost>]

mueller6725%twc.com@localhost writes:

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

That's not clear to me; do you mean that the old version is removed
first, as in make replace, or just that the new version is installed, as
if you had done "rm -rf /var/db/pkg/oldpkg-x.y" first?

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

It's only one command per package that should already have been updated
but hasn't, but I see your point.

It should be possible to make a "package-install-or-replace" target that
builds a package and either does package-install, if not installed or
replace, if installed, and use that as DEPENDS_TARGET.  That of course
trades one problem for another, but it's a reasonable thing to do, given
that you are in an unsound situation to start with.

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

Yes.

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

Yes.  In theory, those depend on osabi, and if not probably there's a
bug, but in  general if something is trouble, you need to update it.

If you don't like the process of noticing trouble and dealing with it,
you should stick to release branches of netbsd and of pkgsrc.

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

Even without that, pkgsrc has updates to packages and if you haven't
reinstalled them, they are then no longer matching.

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

My advice is not to do that.  After you update the pkgsrc tree
(globally), run pkg_rr and fix any problems.

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

Usually, the amount of manual work is fairly small, compared to the
total packages affected.

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

Perhaps; see the pkgsrc tree, the wiki, and various guides on the web.

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

That's also unsound; packages have prefix baked in.   You could
re-bootstrap as /usr/pkg1 /usr/pkg2 and so on.

What I do is run pkg_rr with -k, rm all my workdirs, update, repeat,
until I get to a fixed set of failing packages.  I then rm packages if
the problem is that they build but don't install, noting what to
rebuild.  And packages that don't build, I fix (or complain about!).

You are of course welcome to do as you choose.  But it is not a
reasonable expectation that tracking pkgsrc-current will be free of
trouble.