"Thomas Mueller" <mueller6724%bellsouth.net@localhost> writes: > I wouldn't have thought updating pkgsrc would cause ABI conflicts and > make packages incompatible. Do you realize that the upstream maintainers of packages that are in pkgsrc (and FreeBSD ports, and flavors of GNU/Linux) make changes that break ABI compatibility from time to time, and that this issue is not specifically about pkgsrc? The real question is how a packaging system deals with that problem. > FreeBSD ports system does not have that problem; no problem running > > portsnap fetch update > > I never even heard of ABI in FreeBSD. It certainly exists. I would suggest studying the upgrade code and documentation to figure out how they deal with it. Note that PCBSD has a scheme where all dependencies are included in a package, trading disk space for avoiding dealing with the ABI issue. That's a reasonable decision, but it's unusual. > Now I see why there is a quarterly pkgsrc in addition to current > pkgsrc in NetBSD pkgsrc, unlike FreeBSD ports and source-based Linux > package managers. There is no particular reason why quarterly pkgsrc is more appropriate than quarterly FreeBSD ports. The stability of quarterly branhces is useful to those who build from source as well as those who use binaries. > But I don't want to wait three months when a new release of something > like Gnumeric or Seamonkey comes out; I also might want to test a new > beta release installed to a different prefix to avoid conflict with > installed stable version. If you want the latest, you'll have to endure the pain of ABI changes somehow. Or you can just build a few leaf packages with updated code, which usually works, or build things outside pkgsrc. > What if there is a security update, then > also I don't want to wait for the next quarterly pkgsrc. Security fixes are generally applied to quarterly branches. > I'm afraid running pkg_rolling-replace on a system with a lot of > packages could take an awful long time, like several days. I run it pkg_rolling-replace -uv -k and find that it typically runs for a day after a major update to pkgsrc. But, absent a major ABI break, like the recent png issues, and the jpg one a few years ago, most programs work in the interim. On a server without gtk/gnome/qt/kde installed, it's quite quick. > I see Gentoo (http://www.gentoo.org/) has several projects in the > works, including porting to the BSDs and other quasi-Unixes. > > **Update: I updated pkgsrc (cvs update -dP from /usr/pkgsrc), then ran > > pkg_rolling-replace -suv 2>&1 | tee prr1.log I am not aware of any actual need for -s. It's there somewhat for historical reasons, and needing it more or less indicates a bug in pkgsrc (an unexpressed dependency). I don't remember any cases. [x11-links] One thing which is non-obvious about pkgsrc is that stale work directories cause lots of problems. It looks like you have build x11-links but then removed the binary package. I highly recommend "rm -rf */*/work" before running pkg_rr. Perhaps pkg_rr should change to do "make clean-depends clean" instead of just clean, but that would be time consuming. pkgsrc is certainly not perfect, but it's the best system I've ever used. The underlying problem is very hard, and in analyzing one has to be careful when comparing not dealing with a problem and the resulting complexities of dealing with it. If you have time and inclination to understand how FreeBSD ports currently deals with updates of the ports tree and building new packages (in terms of solving the incompatible ABI problem), an analysis of that and a design for improving pkgsrc would be quite useful.
Attachment:
pgpUaiQDjxXY8.pgp
Description: PGP signature