> Is there some upgrade point after which pkg can automatically *not* show
> this message and it will be safe to upgrade? I guess that's the "fully
> automated" part of the bug...
The issue in question concerns a GRUB flag-day that the engineering
team wasn't aware was coming. It's entirely possible (and perhaps
would have been preferable) to have not resynced with Nevada until the
changes made by ZFS boot in build 88 were changed to be compatible with
earlier the earlier versions of GRUB but I'm not sure if that would
have been possible.
Given where we are today, I believe the right path forward is to fix
1979 libbe: be_activate needs to run installgrub
http://defect.opensolaris.org/bz/show_bug.cgi?id=1979
but longer term, we need a way to handle other such flag-days, some of
which may not be induced by GRUB changes but by something else.
> With regard to the URL, it *should* be something as easy as that.
> Doesn't it have more affinity to indiana or the OpenSolaris distro
> though? ipkg is ostensibly portable, and the image-update subcommand is
> somewhat OpenSolaris specific. There appears to be an official (yet
> unmaintained) doc here: http://dlc.sun.com/osol/docs/content/IPS/ggfwk.html
Actually, that *is* the official documentation and it is maintained but
perhaps the "workaround" isn't documented there (like many such
limitations, it's often documented in the release notes which folks may
or may not read).
> The last time I needed to find the notes on the update, I had to dig
> into the mail archives.
We've talked about providing a feed of each of the release notes on a
build-by-build basis but I don't believe anyone has scoped that out
yet. But it would be great to have a well known page or perhaps a
OpenSolaris knowledge article like the ones available on sun.com/msg.
> I didn't mind a slight bit of pain from the initial release, but it
> seems each image-update is requiring a separate workaround or two. I
> even read things carefully and got hung up on updating SUNWipkg, since
> it wasn't obvious that it was updating to a newer timestamp of the same
> version.
As the release notes indicate, there shouldn't be any workarounds
required at the moment if you're running build 93 or later already.
That's the case whether you installed from the build 93 ISO or had
previously done an image-update. Of course, that doesn't guarantee
we're not going to face similar sorts of flag-days in the future which
means we need 1) a mechanism to help the user across those jumps and 2)
to do better testing prior to pushing out packages.
Of course, the other issue is that the default authority was pointing
to the (unstable) trunk. In the future, we're likely to change this by
pointing the default authority to a stable sustaining branch and a "pkg
image-update" will by default bring over a more extensively tested set
of packages.
dsc
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
