[OpenIndiana-discuss] Hipster upgrade problem

[Jonathan Adams]

On 16 November 2015 at 08:55, Stefan Müller-Wilken <
stefan.mueller-wilken at acando.de> wrote:

> What I'm feeling quite uneasy with is the fact that we now have two
> distributions: hipster that gets more recent software packages & security
> fixes and dev that is said to be the more (or only?) stable choice. Or in
> other words: choose stability _OR_ security - a no-win-situation.
>
> How can we get past this? Either with a well defined approach for staging
> packages from hipster to dev or by providing a bullet-proof list of steps
> on how to upgrade packages in dev directly, similar to
> http://wiki.openindiana.org/oi/Building+with+oi-userland but for dev, not
> hipster.
>
> Or am I missing an important aspect here?
>
> You're not missing the point ...

There was initially a call to have "stable", "dev" and "nightly"
repositories, with a reliable version of "dev" being pushed to "stable",
and "nightly" being a reliable-ish version of "nightly". This however fell
away due to the wants of the "dev" team to stay with Studio and the
"hipster" team wanting to move to gcc.  The split caused problems where the
"dev" branch effectively stopped generating new code and all development
moved to the "hipster" branch.

After the "dev" branch fell silent for about a year, Hans Rosenfeld,
managed to rebuild and repackage the "dev" branch to use the hipster
package versioning system, allowing for the first time those who were on
dev a9 to potentially upgrade to hipster, while this moves them to a more
"nightly" approach, and can cause issues with graphics drivers and certain
java packages, or cause you to upgrade any applications that require a
specific version of php/java/openssl, the kernel that is running on the
system should, in general, be considered to be stable ...

There is no team in place to create a "stable", a "dev" and a "nightly"
now, and because of the work involved, the size of the team, and the status
of the testing process, even getting a new "dev" would be hard work.

My advice though is to not upgrade all the time (weekly/monthly might suit
you best), to keep all of your data out of the root of your disk (e.g.
rpool/export/home, so that it is separate from the BE) and to keep at least
2 BE's so that you can go back if you find that something has broken.

Just my 2cents.

Jon