pkgsrc-Users archive

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

Re: Why are depends rebuilt on "bmake update" ?

Aleksej Saushev <> writes:

> I tried to recover from inconsistent "make replace" with pkg_rolling-replace
> several times and always ended in a state with even more inconsistencies.
> This led to rebuilding of all packages at least two times, and at least one
> time I could get out with pkg_chk. In other cases I performed manual updates
> to recover. This makes me believe that pkg_rolling-replace is not safe
> mechanism.

That sounds unusual.  (If dependencies are not expressed correctly, it
can't work, but that doesn't sound like what happened to you.)

Another problem I should have pointed out is that

  building packages from one pkgsrc version

  updating to newer pkgsrc (but not rebuilding anything)

  make replace on some random package

  pkg_rolling-replace -v

will not work, because many packages will demand specific new versions
of dependencies.  This is not actually a pkg_rr bug, but an underlying
reality of make replace.  To avoid this, I do

  pkg_rolling-replace -uv

which also replaces mismatched packages.  Perhaps this is what you ran

If you have more data abou the problem you had (logs, etc.) I'd be
interested in seeing it.

> I still don't understand why it is recommended to recover from
> inconsistencies.  The way it functions (utilizing unsafe operations)
> doesn't make impression of doing it correctly either.

The theory is actually pretty straightforward:

  pkgsrc normally has a "all dependencies of a program exist, and
  are the right versions" rule.

  when you do 'make replace' on package A, then that rule, assuming it
  was true before, remains true, except that for various packages b that
  depend on A, the dependency might not be ok (wrong shlib version,

  pkgsrc sets flags unsafe_depends on all such packages b when it does a
  make replace on A.  It clears the flag on A, because A was rebuilt
  against what was installed, and thus by definition is ok at that

  Thus, the new rule which is always true is "all dependencies are a
  right/sound version, except that packages flagged unsafe_depends may
  have bad versions of dependencies."

So, if you do a bunch of make replace operations, then if you arrive
with unsafe_depends not set on anything, you should have a consistent

pkg_rr topologically sorts all the packages and does the make replace in
the right order, so that you only replace each package once.  So it is
systematically cleaning the unsafe_depends flags.  That's really all
there is to it.

Taken together, I believe that this approach is entirely sound.  (It may
fail because of package structural changes, but absent dependency bugs
in pkgsrc, one should not be able to arrive at a state with no
unsafe_depends flags and any inconsistency.  That's why I say that it is
sound, even though sometimes it is unsuccessful.)

Separately from the theory, I have been running pkg_rr to update many
systems for over 5 years, and it has basically worked (modulo the issues
in my previous note, which are failures to replace, not integrity
failures once replaced).

Attachment: pgpg0ekRI8eRH.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index