pkgsrc-Users archive

[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 post:

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?

FORCE_PKG_REGISTER removes the old package before installing the updated version.

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

Question will arise when NetBSD 8.99.xx is branched, which should I go with?  Going with both might be too much.

Waiting too long before running pkg_rolling-replace can cause it to not work right due to package renamings and removals.

Sticking to release branches of NetBSD means remaining stuck with bugs, at least in my experience.

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

Not do what?  Context is not clear.

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

I even get "moved or obsolete" message on /usr/packages/All/Makefile not found, but as far as I can see, there is not supposed to be such a file.

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

The idea of an alternative LOCALBASE and PKG_DBDIR is suggested at the bottom of the NetBSD wiki page on how to upgrade packages.

But I would want to put the new packages in the normal directories.

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

Various packages are updated not in sync with quarterly pkgsrc, so it seems illogical to be kept waiting unduly.

Tom



Home | Main Index | Thread Index | Old Index