tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: add PKG_INSTALL_TRY_UPGRADE -- please review

matthew sporleder <> writes:

> Since it's been three+ years I will restate the problem I was
> originally trying to solve:
> I am getting pretty sick of the following workflow:
> cd /usr/src/pkgsrc; cvs update
> cd devel/tig
> make install clean
> ... (an hour later)
> pkg_add: A different version of foo-dependency-1.0.1 is already
> installed: foo-dependency-1.0.0
> pkg_add: 1 package addition failed
> *** Error code 1
> ...
> (grumble) pkg_add -u /usr/src/packages/All/foo-depdendency-1.0.1
> make install
> repeat...
> </quote>

This doesn't work because pkgsrc assumes that all installed packages are
consistent with the current source tree.  There are basically three ways
to deal with this:

  1) after cvs update, run pkg_rolling-replace -uv.  Deal with any
  packages that build from scratch but that don't work this way (files
  moving between packages, renaming, etc.).

  2) pkgin fug to a set of binaries corresponding to the new sources (only
  workable in practice for stable branches), or some similar tool

  3) build packages in a fresh chroot (bulk build, or otherwise), and
  update all packages at once.   This is basically option 2 in the case
  you build the packages yourself.

What you are doing will update some dependency as needed, but that may
well break some other package (that was built against the old version of
foo-dependency).  So the total set of packages won't end up in a sound
state.  Some people don't like anything but fresh builds in chroots
because of this -- but that's harder to set up and takes more space.
pkg_rr is designed to keep track of possible breakage from these updates
and fix it by rebuilding in order.  So IMHO the two reasonable options
are pkg_rr and updating to a consistent set of binaries.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index