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.
Attachment:
pgpU5E5QH3Er3.pgp
Description: PGP signature