Re: add PKG_INSTALL_TRY_UPGRADE -- please review

[matthew sporleder <msporleder%gmail.com@localhost>]

On Tue, May 7, 2013 at 7:59 PM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> 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.
>



Okay I was able to read your reply a few more times.

Anyway, It looks like -U was a previously undocumented option, but it
definitely does look like a better option than just -u.

-u, -U, -U -u don't fail if the package is not already installed.
They do the right thing and just install.

I am still reading up on where using parts of the replace framework
would be better than just using -U.
I like the package backups but what else?