Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-22 Thread Dan McDonald
> On Feb 22, 2017, at 11:35 AM, Peter Tribble wrote: > > I'm not sure I would make -r the default. Apart from the existence of > cases where you explicitly *don't* want to update zones, it makes you > incompatible wit the rest of the IPS world. > > However, the fact

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-22 Thread Peter Tribble
On Mon, Feb 20, 2017 at 10:28 PM, Dan McDonald wrote: > EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from > 014-020 to something different. It also fixes a shortcoming in 014-020. Do > we go completely with the new behavior and document it? Or do we

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-21 Thread Andy Fiddaman
On Mon, 20 Feb 2017, Dan McDonald wrote: ; a.) Accept "-r" as a requirement, and document to users that the behavior between 014-020 and 022-beyond will change. This one gets my vote. It will actually improve our workflow here! Andy -- Citrus IT Limited | +44 (0)870 199 8000 |

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Jim Klimov
21 февраля 2017 г. 3:24:58 CET, Bob Friesenhahn пишет: >On Mon, 20 Feb 2017, Dan McDonald wrote: > >> >>> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn > wrote: >>> >>> If someone forgets to use -r the first time around, can the same

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Jaakko Linnosaari
> On 2017-02-21, at 1.03, Dan McDonald wrote: > > a.) Accept "-r" as a requirement, and document to users that the behavior > between 014-020 and 022-beyond will change. I’m in favour of this change. It’s consistent and suits better with our usage patterns. Thanks, —

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Bob Friesenhahn
On Mon, 20 Feb 2017, Dan McDonald wrote: On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn wrote: If someone forgets to use -r the first time around, can the same command be invoked again with the -r and then the zones get the updates as well? Yes. The pkg5

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Bob Friesenhahn
On Mon, 20 Feb 2017, Dan McDonald wrote: Also, the "-r" flag will be required for "update", "install", "uninstall", "change-facet", and "change-variant" subcommands as well. This is better than I understood since it is consistent. Copious documentation and alerts would be required. If

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Dan McDonald
Also, the "-r" flag will be required for "update", "install", "uninstall", "change-facet", and "change-variant" subcommands as well. Right now, it appears we have two votes for "just accept -r and don't worry about making it implicit." Again, the two choices are: a.) Accept "-r" as a

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Dan McDonald
> On Feb 20, 2017, at 5:37 PM, Theo Schlossnagle wrote: > > New behavior seems much more intuitive and self-consistent. IMHO in with the > new and out with the old. Just so we're clear: You do NOT want "implicit -r" and are okay with the behavior change for "pkg update"

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Bob Friesenhahn
On Mon, 20 Feb 2017, Dan McDonald wrote: Because of the least-suprise violation of new "pkg update" behavior, I'm wondering if we should make "-r" implicit. I'm working right now on an implicit "-r" solution, but am running into some problems with the pkg5 test suite I still need to sort

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Theo Schlossnagle
New behavior seems much more intuitive and self-consistent. IMHO in with the new and out with the old. On Mon, Feb 20, 2017 at 5:28 PM, Dan McDonald wrote: > EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from > 014-020 to something different. It also

[OmniOS-discuss] On pkg(1) behavior in r151022

2017-02-20 Thread Dan McDonald
EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from 014-020 to something different. It also fixes a shortcoming in 014-020. Do we go completely with the new behavior and document it? Or do we minimize least-surprise at the risk of introducing bugs? I'm leaning toward the