Updated perl - broke stuff

[Gerhard Schmidt]

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" <ean at hedron.org>
> > To: <freebsd-questions at freebsd.org>
> > Cc: "Paul Schmehl" <pauls at utdallas.edu>
> > 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: estartu at augusta.de         |   auf Anfrage/
Germany            |                                    |    on Request
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 366 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20050215/2362cf5a/attachment.bin