Date: Sat, 11 Aug 2007 14:07:17 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: freebsd-ports@freebsd.org Subject: Re: How did upgrading applications happen before portupgrade etc? Message-ID: <20070811210716.GB78245@eos.sc1.parodius.com> In-Reply-To: <20070811104229.GD94464@over-yonder.net> References: <20070811115642.L34115@obelix.home.rakhesh.com> <20070811083357.GA34007@eos.sc1.parodius.com> <20070811104229.GD94464@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 11, 2007 at 05:42:30AM -0500, Matthew D. Fuller wrote: > portupgrade manages all the regular /var/db/pkg/*/* files just like > any other tool. It's got its db files, sure, but they're caches, not > alternate masters. I've never seen a "sync mismatch" (or rather, I > see them all the time, when portupgrade sees that the source is newer > than its cache and updates the cache). I'm aware it manages all of the "regular" /var/db/pkg files just like the pkg_* tools do. It has to for it to play nice. But it also maintains a separate database for (I think) versioning and dependency matching. I've been told the reason it does this is "due to shortcomings in /var/db/pkg or the pkg_* tools". Also, if you use portupgrade, you pretty much HAVE to use it exclusively for everything, e.g. you can't go mix-and-matching use of portupgrade and the base pkg_* tools without there being some inconsistency induced and thus "breaking" portupgrade. Am I correct? > I blow 'em away every time I upgrade ruby or ruby-bdb or bdb just out > of GP to head off potential troubles. With the growing number of > installed ports, rebuilding the pkgdb.db files takes a "long" time, > but it's what, a minute? Minute and a half? I think you're referring to things like this: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=367904+0+archive/2007/freebsd-ports/20070204.freebsd-ports Where the only solution is to rm the pkgdb.db file and then run pkgdb -u, correct? > There are certainly reasons to dislike portupgrade (like that it's > slow. Godawful long. Where's-War-And-Peace-I-need-something-to-read > slow. It's almost as slow as yum is on a machine twice as fast), but > I don't understand this one. The db's dont go wonky with any notable > regularity IME, and when they do you just rm 'em and move on. What's > the big deal? If people use portupgrade, awesome. If it makes their lives easier, great. I won't get religious about it if I'm helping someone with their box and they say "Oh, btw, I use portupgrade". My response will be "Alright cool." But if someone asks me "Why don't you use portupgrade" I'm going to tell them why. I see claims like the above ("you just nuke the db and move on. What's the problem?") and I think "What the f***?". Removing a file and ignoring the problem because the problem then goes away (until the next time it happens...) makes me think of a Windows-like solution. "Reboot the box and the problem goes away". IIS /REBOOTONERROR. No thanks. When something breaks on my boxes, I want to know exactly why, and if it's not due to my own fault, I want to either fix it myself + supply a patch (if I'm capable of doing so), or report it and have it fixed. The fact that portupgrade has existed since early 2001 and still continues to have problems like the aforementioned is uncomfortable (in my opinion). It's major enough that it doesn't instill confidence. If it's a minor enough issue to you, then great, no harm done. But it's not a minor issue to me. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070811210716.GB78245>