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

[Peter Tribble]

On Mon, Feb 20, 2017 at 10:28 PM, Dan McDonald <danmcd at omniti.com> 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 minimize
> least-surprise at the risk of introducing bugs? I'm leaning toward the
> second choice, modulo my pkg5 test suite experiences.  Opinions, esp. from
> LTS folks, needed.
>
> .  .  .  .  .  .  .  .
>
> I updated pkg5 during this bloody to handle Python2.7.  That worked all
> well and good, but had a side-effect I didn't see (and neither did a lot of
> bloody users, apparently).
>
> So here's what happens today, on 014-020 pkg(5) for global zone
> invocations:
>
> pkg update <pkg>
> - Updates <pkg> on global zone.  No others, REGARDLESS of linked-image or
> not.
>

That behaviour initially surprised me, but once you understand that all
it's doing in the linked zone is ensuring package compatibility then it
makes sense - the currently installed version of the package clearly has to
be compatible (else it couldn't be present) so there's no need to update it.


> pkg update
> - Update all pkgs on global zone AND on any linked-image zones.
>
>
> Starting with the Python2.7 integration, this behavior changed:
>
> pkg update <pkg>
> - Same as before
>
> pkg update
> - Only updates global zone, and linked-image "If needs sync", where "needs
> sync" is not well defined (may need a property inside a package itself).
>

That sounds like there's a bug somewhere.

If you update the OS in the global zone, with a change that breaks
kernel<->libc compatibility, will libc get updated in an lipkg zone?

The answer has to be yes, clearly.

IPS relies heavily on package constraints, so if that's not happening
then either pkg(5) is broken or package versions aren't adequately
constrained, I guess.


> pkg update -r <pkg>
> - Updates <pkg> on global zone AND on linked-image zones.
>
> pkg update -r
> - Behaves like "pkg update" on 014-020, updates all pkgs on global and
> linked-image zones.
>
>
>
> The "-r" as an option - and you can specify zones with -z or zones to
> exclude with -Z - is new from Oracle with the wad of updates OpenIndiana
> pulled in to get Python2.7 support.  And I quote from the pkg(1) man page
> you can see on bloody today:
>
>           -r
>
>               Run this operation in the global zone and also in all
> installed
>               solaris branded non-global zones. The effect on the
> non-global
>               zone is similar to logging into each non-global zone and
>               running the command directly. Without this option, when you
> run
>               pkg commands in the global zone, non-global zones are
> modified
>               only to the extent required to keep them compatible with the
>               global zone. With this option, the pkg operation is applied
> to
>               all installed non-global zones except as limited by the -z
> and
>               -Z options. Zones that are excluded by the -z and -Z options
>               might still be modified if updates are required to keep them
> in
>               sync with the global zone.
>
> 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 out.
>

FWIW, when updating a single package I have a script that effectively
does -r by doing a zlogin into each zone. So 'pkg update -r' is a good
thing.

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 that a bare 'pkg update' could lead to broken linked
zones does concern me, and I suspect that you're going to have to look
at whether you need to tighten up package and incorporate dependencies.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20170222/cf803f4e/attachment.html>