tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: add PKG_INSTALL_TRY_UPGRADE -- please review



I'd like to revive this old thread.

On Sun, Oct 6, 2013 at 8:23 AM, matthew sporleder <msporleder%gmail.com@localhost> wrote:
> On Fri, May 10, 2013 at 11:12 PM, matthew sporleder
> <msporleder%gmail.com@localhost> wrote:
>> On Fri, May 10, 2013 at 10:16 AM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>>>
>>> matthew sporleder <msporleder%gmail.com@localhost> writes:
>>>
>>>> Anyway, It looks like -U was a previously undocumented option, but it
>>>> definitely does look like a better option than just -u.
>>>
>>> Sorry, I was confused.   The new option is -D, which is in the pkg_add
>>> man page.
>>>
>>>> -u, -U, -U -u don't fail if the package is not already installed.
>>>> They do the right thing and just install.
>>>
>>> OK, but.
>>>
>>>> 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?
>>>
>>> The backups are IMHO not important.
>>>
>>> The point is that semantically what you are doing is exactly what make
>>> replace does.  It's an abstraction violation to open-code this again
>>> separately.  The other part is that make replace updates metadata about
>>> which packages have had dependencies replaced out from under them, via
>>> the unsafe_depends flags.  See mk/pkgformat/pkg/replace.mk for a
>>> detailed explanation.
>>>
>>> Arguably
>>>
>>>  - pkg_add -U should set the unsafe_depends flags, and then the
>>>    unsafe_depends handling can be removed from make replace
>>>
>>>  - pkg_add should have arguments to update a single package, and not try
>>>    to update other packages recursively, and make replace should use
>>>    that.
>>>
>>> but those things aren't yet true.  Even if they are fixed, what you are
>>> trying to do is "install the package, and if it's already installed,
>>> replace it instead", and I don't think we should have repeated logic to
>>> do the same thing.
>>>
>>> Why do you not want this to use the replace target as a subroutine?
>>
>> Two reasons:
>> - I just haven't tried it yet.
>> - I'm not sure how to reliably test if the package is already
>> installed and make replace doesn't handle it for me like pkg_add does.
>
>
> Did these ever get committed?


Home | Main Index | Thread Index | Old Index