Date: Mon, 14 Feb 2005 00:37:28 -0800 From: "Michael C. Shultz" <reso3w83@verizon.net> To: freebsd-questions@freebsd.org Cc: Ean Kingston <ean@hedron.org> Subject: Re: Updated perl - broke stuff Message-ID: <200502140037.30061.reso3w83@verizon.net> In-Reply-To: <20050214023410.GA27186@xor.obsecurity.org> References: <200501271852.j0RIqQ9t010411@mp.cs.niu.edu> <200502131815.21142.reso3w83@verizon.net> <20050214023410.GA27186@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502140037.30061.reso3w83>