Updated perl - broke stuff

Michael C. Shultz reso3w83 at verizon.net
Mon Feb 14 02:58:20 GMT 2005


On Sunday 13 February 2005 06:34 pm, you 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.

I am, I'm going to put together a script that proves it and send it to 
you later tonight.
>
> >   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.

OK, sorry.  I should have been more thoughtful.
>
> > 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.

Your right, it isn't allways needed, that is why portupgrade works most 
of the time.  But when ports do that need to be upgraded with the new 
dependencies and aren't they are damaged.  With no way to accurately 
follow the dependency path of how they were built you have to remake 
everything in the dependency path to fix it.
>
> portupgrade can operate in this mode anyway, though; just add the -f
> option to portupgrade -r.

-Mike




More information about the freebsd-questions mailing list