[OpenIndiana-discuss] recommendations for updating to 151a9

[Jonathan Adams]

jadams at jadlaptop:~$ pkg publisher
PUBLISHER                   TYPE     STATUS P LOCATION
openindiana.org              origin   online F
http://pkg.openindiana.org/hipster/
jds.openindiana.org (non-sticky) origin   online F
http://opensolaris.cz:10000/
sfe-encumbered              origin   online F
http://pkg.openindiana.org/sfe-encumbered/
sfe            (non-sticky) origin   online F
http://pkg.openindiana.org/sfe/
localhost      (non-sticky, disabled) origin   online F
http://localhost:10000/
jadams at jadlaptop:~$



On 22 January 2014 20:05, Tim Mooney <Tim.Mooney at ndsu.edu> wrote:

>
> - it recommends removing opensolaris.org as a publisher.  I didn't add
>   that, so it must have come from the OI151a8 install I did.  Should I
>   really remove it?
>

I did, unless you want legacy software, for old OpenSolaris/Indiana
distributions you won't need it in the future.

- it recommends using "image-update".  That doesn't seem to be documented
>   in the "pkg" man page.  How does it differ from just "update"?  Is it
>   just deprecated syntax that's been replaced by "update"?
>

I don't _know_ the answer, but they both appear to do the same thing, and I
have used just "update" for the last year+


> - this is a desktop workstation, so I've installed quite a few
>   media-related packages from sfe, and a couple from sfe-encumbered.
>   After I set sfe and sfe-encumbered as non-sticky,
>   the "pkg update -nv" had no conflicts, but I'm uncertain what that
>   means for the packages I've installed from sfe or sfe-encumbered.
>
>         - should I just remove all of them before I do an update?
>

no, only bother to remove if there is a conflict.


>         - will the fact that sfe and sfe-encumbered are now non-sticky mean
>           that the updates that come from /dev will leave sfe packages on
> the
>           system, but in a broken state?  Or, will the update automatically
>           remove stuff from sfe/sfe-encumbered if their dependencies are no
>           longer met?
>

the usual conflicts are when there are permission changes on the files in
the packages, or if there is an overlap of files.

If a newer package appears in any repository, that has non-conflicting
permissions then the update will just move to that package, even if it is
in a different repository.  setting stuff non-sticky just allows it to do
that.

Jon

PS. All information contained in this email may be wrong, and probably is,
but it worked for me :)