[OpenIndiana-discuss] Testing updates from /dev to /hipster-2015 and /hipster

[Nikola M]

On 05/12/16 06:27 AM, bentahyr at chez.com wrote:
> Hi,
>
> For the moment I just notice tiny differences :
> - openvpn on /dev comes from sfe and uses /etc/openvpn/config as default
> config file
> - openvpn on /hipster-2015+ comes from main and uses
> /etc/openvpn/openvpn.conf as default config file
>
> Testing more package is quite hard, for example I only discovered the
> difference between the config of openvpn because I actually used it.
This is great to note those config changes so that it can be documented
and/or release notes can be used to fill in how many packages has been 
changed with according settings to be checked.
I think that in general we should focus on updating packages only,
does they update replacing old /dev ones without issues per se.
It's in general admin's problem to check and update their configs on 
updated packages and to prepare and transfer configs to newer version in 
this stage, if we provide changed packages list.

At a later stage, when we start jumping in between hipster snapshots 
landing in /dev, there could be space for in-detail manuals and warnings 
in release notes about every changed component and it will grow 
organically from every change/package update inside hipster, together 
with testing it before landing in /dev.

> Anyway is there a way to install every package other than pkg install
> pkg:/* (which doesn't work) ?
> If I can install all packages, I'll try an update see which packages are
> missing but I won't be able to check config or functionality difference
> of everything.

That is good enough.
Let me get back to you on best method of all packages install/upgrade test.

Depending on that we'll see if we can support all packages installed or 
must require for some of them uninstalled before update and what could 
be changed to facilitate update.

Primary concern is that things are up datable and that it goes smoothly.
General notices for most important services will be provided after we 
make sure we can update /dev (with publishing in /dev-test in between) 
and make a bridge and that we can reproduce a /dev landing process 
afterwards.