matthew sporleder <msporleder%gmail.com@localhost> writes: > I don't think this is how many pkgsrc users work. I think cvs update > to an existing tree is the norm. Sorry, I meant to include "cvs update at top level of a tree" within "consistent checkout". >> So, I see two possible approaches: >> >> After you do the cvs update, then use pkg_rolling-replace. It will do >> 'make replace' in the right order (mostly), and this will mostly work. >> >> something along the lines of what you are doing > > Yes, I know there are a few tools to do this sort of thing. I am > trying to get the 80% solution/ease the one workflow I described. Understood, and that's fair enough. I just wanted to explain some of the other issues. >> As for your specific approach, I think it has a bug, because when a >> package is installed, either there is a version, or there isn't. So >> what I'd suggest is to add a target (NB I am assuming a DESTDIR world >> here): >> >> package-install-or-replace: >> >> that says >> >> if the package is installed, do make replace >> if the package is not installed, do make package-install >> >> and then you can set DEPENDS_TARGET to package-install-or-replace. >> >> Alternatively a PKG_INSTALL_USE_REPLACE variable. >> >> Note that make replace is basically pkg_add -u. However, make replace >> also uses -U, to avoid exact-version dependency checks that will fail. >> >> Also, once you do a make replace, there will be dirty >> ("unsafe_depends=YES") packages. To fix this those should also be "make >> replace"d. But once you do that, and add ordering, you've reinvented >> pkg_rolling-replace. >> >> Still, I think your proposed change is useful. > > I thought pkg_add -u would be easiest because of the way we build > binary packages for each pkg. > Also make replace comes with a huge set of warnings. It does, but your proposed change is basically reimplementing make replace (in a DESTDIR world), omitting printing the warning, and also not using the -U flag. So I don't see any reason not to execute make replace as a subroutine rather than open-coding a simplified version of it. The two things that make replace does compared to "pkg_add -u" are pkg_add -u -U. This allows replacing foo-1.0 with foo-1.1 when there is a bar that depends on foo =1.0 (rather than foo >= 1.0). Without this loosening, there is no way to replace foo without removing bar bookkeeping of "unsafe_depends". The idea is that when a package foo is replaced (which pkg_add -u does), then all packages depending on foo are in an unsafe state, because things might not be ok using the new package (ABI changes in shlibs or script behavior). So make replace sets the unsafe_depends variable, and pkg_rr uses that to decide what needs replacing. > Anyway, I'm probably not grokking your entire argument. (as you > mentioned can of worms earlier) The can of worms is that when you want to move from an installed set to another installed set via source, without doing a bulk build from scratch in a chroot sandbox, you are going to run into problems where the new version of A conflicts with the old version of B, etc., which are basically intractable, and you have to delete with -f or remove a lot and rebuild. This isn't super frequent, but it doesn't require some thought. But, with pkg_rr, your thought is basically on those issues, with the mechanical stuff dealt with. So basically I'm saying your idea is sensible, but leaves out some issues - but is still worth doing. However, I don't think you can just add -u to pkg_add, because that should fail if the package is not already installed. And, if the package is already installed then the right behavior is to use -U and update the unsafe_depends variables, and that's exactly what make replace does. I suspect in your manual/painful workflow, you could type 'make replace' when the install fails. So I'm really just suggesting changing your manual workflow in that way, and then automating failing over to make replace when make package-install fails. I think the net result will be the behavior you are trying to get. I think it will often be useful, but that it will end up causing trouble when all sorts of libraries need to be updated (say when libjpeg has a shlib bump). But for many cases it will probably be ok.
Description: PGP signature