Re: CVS commit: pkgsrc/mk/flavor/pkg

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Jun 12, 2010 at 07:57:16PM +0000, David Holland wrote:
> On Sat, Jun 12, 2010 at 09:38:49PM +0200, Joerg Sonnenberger wrote:
>  > > That sounds like "no one should ever use make replace".  No, it isn't
>  > > the correct behavior, if one accepts that make replace causing an unsafe
>  > > state and pkg_rr doing a further make replace to straighten things out
>  > > is reasonable.
>  > 
>  > Consider things like updating from one PHP or Perl version to another.
>  > It is not "unsafe", it is downright broken. Fundamentally broken. This
>  > is different from osabi as it will normally continue to work.
> 
> I think you got this paragraph mangled?

No, I meant what I said. Most users of osabi will continue to work e.g.
across updates on netbsd-4 or netbsd-5.

>  > I am using "make replace". I do know when it is sane to use and when
>  > not. What you are doing is "I don't care about breaking dependencies".
> 
> Anyway, your reasoning is spurious. There *is* no useful way to update
> Perl besides pkg_rr or similar without setting up a whole extra pkgsrc
> installation to do bulk builds in.

My reasoning is that there is no sane way to do incremental updates of a
tiny version bump of Perl. All Perl modules are broken in the mean time,
so the incremental updates provide at best zero value. "make replace" by
itself works well for exactly one case: no ABI constrain was broken.
That case can and will be addressed directly, so that the "unsafe" part
becomes redundant. The issue of shared major bumps can to a degree be
solved by placing shared libraries in isolated subpackages (that can be
kept independently from the rest of the package) and enforcing shared
library bumps in other packages. pkg_rr only provides value for this
case because most library dependencies are not really transitive and
most ABI changes are not immediately fatal. If they are fatal, pkg_rr
just makes issues worse by letting programs crash mysteriously. The
final case I already mentioned -- all or nothing updates. Once you
updated the perl package, all your perl modules are useless without
special hacks. It is as simple as that. With Python, there is at least
some degree of work to prevent packages of the same version to conflict,
but it is incomplete. If I cared enough and had to support such a
configuration for personal or business reasons, I would likely change
Python to use a version specific bin directory with alternate handling
providing the symlinks in PREFIX/bin. This never really was done for
Perl though.

Joerg

Joerg