Thomas Klausner <wiz%NetBSD.org@localhost> writes: > On Sat, Jun 12, 2010 at 12:53:44AM +0000, Greg Troxel wrote: >> Module Name: pkgsrc >> Committed By: gdt >> Date: Sat Jun 12 00:53:44 UTC 2010 >> >> Modified Files: >> pkgsrc/mk/flavor/pkg: replace.mk >> >> Log Message: >> Repair regression in "make replace" in DESTDIR case. >> >> "make replace" is defined to replace a package with a newer version, >> and update depdending packages to depend on the new version. It has >> long been understood that this is not always safe, with the responses >> being "tell people to be careful" and the unsafe_depends variable >> scheme and pkg_rolling-replace. In the DESTDIR case, make replace is >> implemented by pkg_add -U. Usually, this is fine - even if the >> ABI/shlib majors have changed, the package is replaced, and then a >> later make replace of unsafe_depends=YES packages, either manually or >> via pkg_rolling-replace, will bring the system to where it should be. >> However, there are pinned dependencies on osabi where the depending >> package will not accept the new version, and that causes pkg_add -U to >> fail. This is incorrect, as a) those packages don't depend on the >> osabi exact version any more than packages depending on jpeg depeend >> on the particular shlib major, yet jpeg dependencies aren't pinned. >> And, osabi changing version is not necessarily an ABI change - >> consider 5.0_STABLE just before 5.1RC1 and just after, where only the >> version string changed. > > The whole idea of osabi was that it is used by packages where the > OPSYS version matters. > If you update your OPSYS, you should reinstall osabi and all its > dependencies. I'm not sure how to make the work correctly with 'make > replace', but this change doesn't feel correct to me. I think it is correct. 'make replace' is by itself an unsafe operation, and has for the last 4 years done bookkeeping to mark depending packages as "unsafe_depends". There's nothing special about osabi - any package that has a shlib bump has exactly the same consequences. The combination of make replace as used by pkg_rolling-replace, on the other hand, is safe (once pkg_rr finishes), because every package that has been made dirty by having a dependency replaced out from under it is then itself rebuilt, in the right order. There are basically two approaches to updating packages. One says "never allow anything unsafe to be installed", and that leads to "when you need to update something, recursively remove all depending packges. Then, rebuild or reinstall them". This school leads to "make update", and to making a pkg_chk.conf list, building binary packages in a chroot, and installing them. I don't object to this approach, and in fact sometimes use it. It's safe, but it ends up with the system not having installed packages for a considerable time (esp in the 'make update' case). The other approach is to do 'make replace' on things you want to update, and then to do more make replace operations to clean up packages marked unsafe_depends. Before unsafe_depends and pkg_rr, this was hit or miss. With pkg_rr, it is sound. There is a period of time when packages have bad dependencies and may not work. But very often they do work. So these two schools each have minuses, and they are different. pkgsrc users are choosing which they want based on which problem they'd rather have, and I think that's fine. (I don't mind osabi existing - I think that's great, and it forces rebuilds of packages that depend on the OS. The test pkg_rr run with my change replaced libgtop and a bunch of other similar stuff, which is the right outcome.) So if we're going to have 'make replace' at all, then it should be usable with the 'replace anyway, and sweep through fixing up others' paradigm. This is how it has been ever since pkg_rr was written, and that's why make replace failing to update osabi is a regression. I realize you don't use make replace, and clearly Joerg doesn't. But many others do, and I don't think it's reasonable to say that no one should ever use it. > The whole idea of osabi was that it is used by packages where the > OPSYS version matters. > If you update your OPSYS, you should reinstall osabi and all its > dependencies. I'm not sure how to make the work correctly with 'make > replace', but this change doesn't feel correct to me. So I agree with "should reinstall osabi and dependencies". What I've done is cased pkg_rolling-replace to do exactly that.
Attachment:
pgpp_BKYL2HiB.pgp
Description: PGP signature