On Sun, Feb 13, 2005 at 06:15:18PM -0800, Michael C. Shultz wrote: > On Sunday 13 February 2005 02:02 pm, Paul Schmehl wrote: > > ----- Original Message ----- > > From: "Ean Kingston" <[EMAIL PROTECTED]> > > To: <freebsd-questions@freebsd.org> > > Cc: "Paul Schmehl" <[EMAIL PROTECTED]> > > Sent: Sunday, February 13, 2005 3:42 PM > > Subject: Re: Updated perl - broke stuff > > > > > I stopped using portupgrade because it only upgrades ports that are > > > out-of date. It then modifies the installed software database to > > > change any dependencies that relied on the old port to show them as > > > relying on the new > > > port. > > > > > > For most ports, this works. For Perl, particularly mod_perl, this > > > doesn't work. If you install a new perl you have to rebuild > > > everything that depends > > > on perl even if it hasn't been updated. > > > > > > So I stopped using portupgrade. > > > > Wouldn't it make more sense to fix mod_perl? (Or portupgrade - > > whichever one is the culprit?) All the ports that depended upon perl > > appear to have had their dependencies updated properly except for > > libwww and mod_perl. ISTM, fixing those two ports makes more sense. > > > > If you don't use portupgrade, then what *do* you do? Wouldn't you > > have to deinstall and reinstall every port that depended upon perl? > > Or will pkgdb -F do the trick? > > 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. > > 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. > > 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
I don't see why any port should be rebuild just because a Port it
depend on is updated. In more than 99% of all cases this is not needed.
you whould en up in rebuilding openoffice or mozilla/firefox quite often.
Correct me if im wrong. But most of the problem was caused by the fact
that the installation directory of the perl modules has changed with the
update. That's a Problem that ist unique to script languages like perl,
ruby and python, and don't affect the vast majority of the Ports.
Most ob the dependencies a of the type program A uses program B or
program A uses a library ob program B. In both cases there is no
need for an update of program A when program B is updated because
programm a will work well with the new version of program b or more than
just a recomile is needed to make it work with the new version.
I might have helped if with the update of the perl ports all ports
depending on perl would have been version bumped. So portupgrade had
updated them with the perl port automaticly.
I don't see where there is cheating with the update ob the dependency
information.
You install port A and port B. port B depends on port A.
after some time you update port A to a new version. port B still
works without a problem. But port B still has the dependency for
the old version of port A. Some time later you try to delete
program A. There is a hell of work to be done finding out if any of
the ports still installed need this port if the dependency information
is not consisten with the installed version numbers. The dependency
infomation should reflect the information what other ports are needed
and not the information which version of a port A was installed on
the system on building time of port B.
It should be the responsibility of a Port Maintainer to decide if a
port has to be rebuild or not. A port maintainer can trigger a rebuild
with a bump of the port revision.
In case of such a widly dependen port like perl this bump could be done
by the portmgr.
A totaly different problem is the fact that the update of the perl port
didn't update the information in /etc/make.conf. So the rebuild ob all
dependend ports din't work until you called use.perl ports yourself after
afterthe perl update.
just my 2 cent.
Bye
Estartu
----------------------------------------------------------------------------
Gerhard Schmidt | Nick : estartu IRC : Estartu |
Fischbachweg 3 | | PGP Public Key
86856 Hiltenfingen | Privat: [EMAIL PROTECTED] | auf Anfrage/
Germany | | on Request
pgpi0095AEUmi.pgp
Description: PGP signature
