Updated perl - broke stuff

[Michael C. Shultz]

On Sunday 13 February 2005 06:34 pm, Kris Kennaway wrote:
> On Sun, Feb 13, 2005 at 06:15:18PM -0800, Michael C. Shultz wrote:
> > Pkgdb -F is what screws up the installed ports registry. Here is an
> > example of what happens:
> >
> > 1. port-A needs dependency port-B installed
> > 2. port-B is installed
> > 3. port-A is installed and marks its registry as being dependent on
> > port-B
> >
> > and here is where things go wrong using sysutils/portupgrade:
> >
> > 4. port-B gets upgraded to port-B.1 and portupgrade reports port-A
> > has a stale dependency.
>
> Are you certain about this?  This is not what portupgrade is supposed
> to do.
>
> >   Then you run pkgdb -F and port-A's registry is changed to say it
> > was built with port-B.1, portupgrade claims this "fixes" the
> > registry when it really breaks it.
>
> You're using emotionally loaded language here ("breaks it",
> "cheats"), which isn't conducive to discussion.  You have a different
> opinion of what the upgrade process should be doing, but that doesn't
> mean that portupgrade is broken.
>
> > Remember, port-A was built with port-B, not port-B.1 and the
> > correct way to "fix" the stale dependency is to upgrade port-A so
> > it is built with the newer dependency.
> >
> > sysutils/portmanager also updates ports, put it doesn't cheat. When
> > port-B became port-B.1 portmanager will rebuild port-A using
> > port-B.1 as the dependency.  port-A's registry stays reliable,
> > reflecting how the port was really build instead of how we wished
> > it were built.
>
> This is usually not needed, though, so it's overkill and causes
> unnecessary recompilation.  In the cases when it is (e.g. shared
> library bump), the PORTREVISION of dependent ports should be updated
> so they become out of date.
>
> portupgrade can operate in this mode anyway, though; just add the -f
> option to portupgrade -r.
>
> Kris

portupgrade -rf forces the rebuild of the port and ALL of its 
dependencies, and it builds them  in the wrong order, it is nothing 
like portmanager.

example:

if the following are installed:

masterPort-0.0
dependentPort-A-0.0
dependentPort-B-0.0

then

dependency-A-0.0 is upgraded
to dependency-A-0.1

portupgrade -rf masterPort-0.0

will build the following in the following order:

masterPort-0.0
dependentPort-A-0.1
dependentPort-B-0.0

portmanager -u will do the following:

dependentPort-A-0.1
masterPort-0.0

There is a huge difference here!  Portupgrade
builds the top level port before it's dependencies,
then proceeds to build all of the dependencies wither
they need it or not.

Portmanager builds the old dependency first, then unlike
portupgrade,  builds the top level port from the upgraded
dependency and does NOT build the dependency that was
never upgraded.

-Mike