tech-pkg archive

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

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

>   | 1) If one follows the normal
>   |    pkgsrc dependency rules, as is done by "make update" or the
>   |    traditional or new pkgsrc bulk builds, when a package a given
>   |    package depends on has been updated, you need to rebuild the
>   |    package in question too.
> I'm not sure if make update does that or not (given that binary
> packages exist, I consider it a disaster, and won't go near it).

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.

> But what you're suggesting would mean that every time some trivial
> revision happens to one of the "used everywhere" low level packages
> that just about everything would need to be recompiled - for no
> good reason, but "just because".   That's absurd.

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

> Occasionally a package will break binary compability with its callers,
> requiring other stuff to all be recompiled (as now with the perl
> upgrade) - pkgsrc does not yet have any good way to indicate that
> (if it did, when you built the new perl, you could have just had
> it say - ABI comcompatible with perl<5.10 and then all packages that
> were built againsg 5.8.* (or anything else like that) would become
> incompatible, and require rebuilding without any more work.

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

> ps: see PR 39731 for exactly how the perl upgrade caused a real problem.

Eh, I think the PR# is 39734.  I've never used pkg_comp myself,
but have been told that it itself doesn't do much else than build
one or a set of packages inside a chroot.  How you then decide to
use the resulting binary packages is sort of independent of the
build method, no?  Again, my unfamiliarity with pkg_comp may be
showing here.

So...  Would bumping the revision number for all packages which
(directly or indirectly) depend on perl5 have made your problem
not occur?  (Bumping may happen for different reasons anyway,

Best regards,

- Håvard

Home | Main Index | Thread Index | Old Index