From owner-freebsd-questions@FreeBSD.ORG Tue Feb 15 18:17:59 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B838816A4CF for ; Tue, 15 Feb 2005 18:17:59 +0000 (GMT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD3443D55 for ; Tue, 15 Feb 2005 18:17:59 +0000 (GMT) (envelope-from reso3w83@verizon.net) Received: from ringworm.mechee.com ([4.26.84.7]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050215181755.GAUX27026.out002.verizon.net@ringworm.mechee.com> for ; Tue, 15 Feb 2005 12:17:55 -0600 Received: by ringworm.mechee.com (Postfix, from userid 1001) id 973062CE740; Tue, 15 Feb 2005 10:13:38 -0800 (PST) From: "Michael C. Shultz" To: freebsd-questions@freebsd.org Date: Tue, 15 Feb 2005 10:13:37 -0800 User-Agent: KMail/1.7.2 References: <200501271852.j0RIqQ9t010411@mp.cs.niu.edu> <200502131815.21142.reso3w83@verizon.net> <20050215140211.GB95997@augusta.de> In-Reply-To: <20050215140211.GB95997@augusta.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502151013.38177.reso3w83@verizon.net> X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [4.26.84.7] at Tue, 15 Feb 2005 12:17:55 -0600 Subject: Re: Updated perl - broke stuff X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 18:17:59 -0000 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" > > > To: > > > Cc: "Paul Schmehl" > > > 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@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