Date: Sun, 13 Feb 2005 18:34:10 -0800 From: Kris Kennaway <kris@obsecurity.org> To: "Michael C. Shultz" <reso3w83@verizon.net> Cc: Ean Kingston <ean@hedron.org> Subject: Re: Updated perl - broke stuff Message-ID: <20050214023410.GA27186@xor.obsecurity.org> In-Reply-To: <200502131815.21142.reso3w83@verizon.net> References: <200501271852.j0RIqQ9t010411@mp.cs.niu.edu> <200502131642.59595.ean@hedron.org> <04e901c51217$c3d5e590$7702a8c0@officeeagle> <200502131815.21142.reso3w83@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=20
> example of what happens:
>=20
> 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=20
> port-B
>=20
> and here is where things go wrong using sysutils/portupgrade:
>=20
> 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=20
> built with port-B.1, portupgrade claims this "fixes" the registry when=20
> 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=
=20
> to "fix" the stale dependency is to upgrade port-A so it is built with=20
> the newer dependency.
>=20
> 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
--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCEA4iWry0BWjoQKURAjs+AKCpkX0WT+54/1swnYR0dRPgbRE45wCgurtT
UNWB8yhbbigcEE0Zz+coBT0=
=ItMS
-----END PGP SIGNATURE-----
--TB36FDmn/VVEgNH/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050214023410.GA27186>