How did upgrading applications happen before portupgrade etc?

[Jeremy Chadwick]

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 |