From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 9 00:27:38 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3F3016A400 for ; Fri, 9 Feb 2007 00:27:37 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 8DEC913C4B6 for ; Fri, 9 Feb 2007 00:27:37 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 94320 invoked by uid 1001); 9 Feb 2007 00:28:31 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Thu, 08 Feb 2007 19:28:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17867.49198.783462.497178@bhuda.mired.org> Date: Thu, 8 Feb 2007 19:28:30 -0500 To: "Henry Lenzi" In-Reply-To: <8b4c81f0702081553j7168846aj13c5b191d4bfb408@mail.gmail.com> References: <8b4c81f0702061514r5a753e48yea0ce9b937236fc3@mail.gmail.com> <17865.6041.605201.772296@bhuda.mired.org> <8b4c81f0702081553j7168846aj13c5b191d4bfb408@mail.gmail.com> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: pkg_add does not backtrack, does it? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 00:27:38 -0000 In <8b4c81f0702081553j7168846aj13c5b191d4bfb408@mail.gmail.com>, Henry Lenzi typed: > On 2/6/07, Mike Meyer wrote: > > In <8b4c81f0702061514r5a753e48yea0ce9b937236fc3@mail.gmail.com>, Henry Lenzi typed: > > > I haven't found the pkg_add code (it's in Ruby, is it?). > > > > It's in /usr/src/usr.sbin/pkg_install/add. And no, it's not in ruby. > > > > > But from the behaviour of pkg_add -r, it's safe to say that it > > > doesn't backtrack to resolve dependencies, does it? > > > > Why should using a remote repository change the behavior of pkg_add? > > > > Are you sure you're not thinking of portupgrade? The -r otion to it > > causes things to be recursive, and it is sourced in ruby. And it's in > > the ports tree, not the base system (because it's sourced in ruby), so > > you'll need to look for the source (or maybe a tarball) there. > > > > > Like, for instance (a real example), during gnome2 installation on 6.2: > > > > > > warning: 'gstreamer-plugins-gconf-0.10.4_3,2' requires > > > 'gstreamer-plugins-0.10.10,2', but 'gstreamer-plugins-0.10.9,1' is > > > installed > > > > What I was saying is that, one way to go about it manually is hit > Ctl-C, uninstall version 0.10.9,1, then proceed - because the update > required package will be fetched (0.10.10,2). I was commenting the > pkg_add did not do that - detect an outdated version and act upon that > knowledge. i.e., removing it and installing the new one. Otherwise you > would end up having wrong dependencies. This, of course, with pkg_add > for stufflike Gnome, or KDE. Um, if you stopped, uninstalled 0.10.9,1 and then installed 0.10.10,2, then everything that required 0.10.9,1 winds up with a broken dependency. Depending on the nature of the dependency, uninstalling 0.10.9,1 may well cause those applications - and not just their dependency information - to be broken. What pkg_add does doesn't break the dependency graph - you just wind up with two versions of the package installed, one of which may be broken. More importantly, it cuts down on the number of cases where applications break, because the cases where replacing a port with a newer version breaks a dependent port is usually where a file in the old version doesn't exist in the new version - typically a shared library that's changed version numbers. Installing them both means both files are there, so the things keep working. Doing this "right" requires that you uninstall any ports that depend on the old port, then uninstall the old port, install the new port, then reinstall all of it's dependencies. When I think of classic AI backtracking strategies, they always search *trees*. The dependency relationship is a DAG (at least, I hope there are no cycles!). That makes things noticably harder. In particular, since you need to go both up and down the tree, so you *can* encounter cycles, which isn't true with a tree. > Portupgrade, AFAIK, does upgrade fetching source, right? It's not the > same thing. Portupgrade can install from sources, from binaries using sources if the binary isn't available, or only using binaries. It also will move shared libraries in ports it's removing to a compatability directory, so that ports dependent on them won't break. Using "portupgrade -aR" will reinstall all installed packages that are out of date, and all packages that depend on them. Adding a "P" will make it try to install binary packages; adding "PP" will cause it to only use binary packages. As others have noted, you need an up-to-date copy of the ports tree and INDEX for portupgrade. To do what it does, portupgrade needs both the dependency information for the installed packages (this is, in theory, available in /var/db, but the available tools make it trivial to break that database) *and* the dependency information for all the packages you're going to be installing. That's in the ports tree and INDEX files. If you were installing only binary packages, you could in theory build the later by fetching each package in turn and extracting it's dependency information. You would need to do this *before* you installed any new packages, because the order that you install them in is important. As a final aside, I once discussed this with Jordan, and he claimed that his decision to have pkg_add do both installation and dependency checking was a mistake. It would better to have one tool for manipulating packages - extract dependency information, install, deinstall, etc. - and one tool that dealt with the tree. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.