[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: add PKG_INSTALL_TRY_UPGRADE -- please review
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
>>> 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
>>> 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
> 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?
Main Index |
Thread Index |