Updated perl - broke stuff

[Michael C. Shultz]

On Tuesday 15 February 2005 06:02 am, Gerhard Schmidt wrote:
> 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.

Building openoffice from sources is foolish for most people anyways,
in portmanager a sensible person would -ip it and only use the
openoffice package.  mozilla/firefox do much better if you rebuild them
after their dependencies change.  I run firefox and never have the sort
of problems with it that people report in freebsd-gnome at freebsd.org

Most of the /usr/ports/UPDATING entries can be avoided if ports
are built in the correct order and the +CONTENTS entries are kept 
accurate of each port. I test portmanager by setting my ports tree back
to 2004.12.01 then upgrading everything backwards, then upgrading
everything from 2004.12.01 to the present just to make sure it can
handle the UPDATING entries automatically.

I can do this because all +CONTENTS files on my system are accurate.

In reply to your short statement:

" 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"

that last 1% can sure wreck havock when not properly upgraded.
>
> 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.

Why should all ports be bumbed when they haven't changed? Portmanager
knew to rebuild them without the version bump. Why should 
portmaintainers have to modify their ports to support portupgrade? 
Seems it should be the otherway around to me.
>
> I don't see where there is cheating with the update ob the dependency
> information.

The contents file is created when a port is installed lists exactly
what dependencies it uses at the time of installation.  Anytime
you want to see how a port was built you may run make all-depends-list,
and retrieve this info.  As long as +CONTENTS file is accurate
intellegent decisions can be made on how to upgrade the port in
changing circumstances.

Now comes along portupgrade and modifies this +CONTENTS file
and now there is no accurate record of how this port was build.

With the uncertainty caused by modifying +CONTENTS files intelligent
decisions on how to upgrade are not as reliable so we have to do work 
arounds like keeping a /usr/ports/UPDATING for example. Read through
UPDATING and see for yourself the silly hoops we make people jump 
through all because we are too lazy to keep accurate records of how 
ports are installed. 
>
> 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.

You expect the maintainer of perl to notify every maintainer of
ports that depends on perl to bump their versions?
>
> 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
>
-Mike