Re: Problems with old "p5" packages and new "perl5" package

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 16 Oct 2008 23:02:49 +0200 (CEST)
    From:        Havard Eidnes <he%NetBSD.org@localhost>
    Message-ID:  <20081016.230249.71110495.he%uninett.no@localhost>

  | It does.  As does both of the pkgsrc bulk tools.
  | Myself, when I update a pkgsrc installation, I usually use a
  | "proof-of-concept" script which uses pkgdepgraph and pre-built
  | binary packages from a bulk build -- that way the "downtime" for
  | the installation is minimized while being safe with respect to
  | the package dependencies.

I do a similar thing, it isn't the downtime while updating that's
the big issue, it's the delay between when a new version becomes
available and when it can be deployed.  If that should happen to
mean rebuilding kde and openoffice & firefox & ... then that might
mean days (and even for a perl update, that's possible, for reasons
I didn't bother to attempt to understand glib2 depends (runtime) upon
perl, so by your method, updating perl means rebuilding glib2, and
everything that depends upon that - which is half the known universe).

That's despite the fact that there's almost no way that glib2 cares
what precise version of perl is out there (I can't even guess why it wants
perl, but that's a different issue).

  | Well, that's how to be 100% safe all the bits really do fit
  | properly together, at least that's how I understand it.

For 100% even that isn't good enough, after all there may have been
a subtle semantic change in the new version of whatever it is - just
recompiling won't fix that, if the change affects things the code of
the using application may need to be rewritten.

But most of the time that kind of thing doesn't happen, in general
the people who maintain the building block packages do a fairly good
job of keeping backwards ABI compatibility.  And when they can't
it is usually fairly well documented.

  | It has been suggested that the @pkgdep line in +CONTENTS for the
  | p5-* packages built for 5.8.* should have had the contents of
  | "perl>=5.8.7 && perl<5.10.0" instead of just "perl>=5.8.7" as
  | they do now.  However, that would have required the knowledge
  | about in which version the perl community would introduce
  | incomatibilities at the time when the first perl 5.8.* package
  | was initially committed to be really useful.  "Difficult."

Yes, attempting to predict the future is one of the more difficult
problems...   That's why we really need a mechanism where that kind
of thing can be imposed afterwards - effectively adding the clause

        && perl<5.10.0

to every dependency perl>=* (where * < 5.10.0 of course).  That gets added
when the 5.10.0 becomes known, not before.  So, while we might guess
now that the next major problem will be 5.12 we don't know that, and
perhaps some serious problem might cause the need for an update to 5.10.1
with an ABI incompatibility to 5.10.0 - who knows?

See PR 35012 (I think I have the number right this time) for more on
that general problem.

  | > ps: see PR 39731 for exactly how the perl upgrade caused a real problem.
  | 
  | Eh, I think the PR# is 39734.

Oh yes, sorry, the two of them were next to each other in my list
of PRs and I guess I just read the number off the wrong line!

  | I've never used pkg_comp myself,

You should try it - but it has nothing at all to do with that particular PR
I don't think.   Nor has NetBSD 3.0 - I just include all that info in the
PR for completeness, and just in case something odd that I didn't know about
made it relevant.

This time the exact same thing would have happened in every build environment
that attempts to use binary packages when they're available (anything using
pkgsrc's "make bin-install" - which is what I used to do before pkg_comp
automated exactly that).

  | but have been told that it itself doesn't do much else than build
  | one or a set of packages inside a chroot.

That's right, it just creates a cleanroom to build things (and a fairly
nice interface to play around in).  As far as building goes, it isn't
any different than the bulk build sandbox I guess.

  | How you then decide to
  | use the resulting binary packages is sort of independent of the
  | build method, no?

Yes.

  | So...  Would bumping the revision number for all packages which
  | (directly or indirectly) depend on perl5 have made your problem
  | not occur?

The way I do things, the problem would have vanished, as I remove all
out of date binary packages before I start building anything (failing to
do that causes all kinds of problems that are difficult to overcome).
Anything that's known out of date gets built from source.  Packages
that are still up to date get installed from the existing binary.

  | (Bumping may happen for different reasons anyway, though.)

For the p5-* packages it no longer matters to me, I went and trashed them
all after filing the PR, so they're all getting rebuilt as they're
needed (that's going to mean that I now have other packages that
depend upon p5-* packages that no longer exist, but eventually all that
will get sorted out - a revbump on all of them would make that
happen quicker).   It also means that I'm not building binary packages
that end up having the exact same name as the packages I had before,
but are different inside.  That I consider to be a bug.

kre