On 05/01/12 14:46, Danek Duvall wrote:
Bart Smaalders wrote:
There are two warring principles here: absolute repeatability of
installs, and up-to-date info. We could obviously update the package
containing the release notes in the repo such that a newer version would
be installed, but then the install is (very slightly) different, even
if the binaries are exactly the same.
I'd be tempted to say that for this specific case, the benefit of providing
up-to-date info outweighs the risk of non-repeatable installs. This isn't
nearly as scary as when we were incorporating packages at too coarse-grained
a level to allow for respins but for an update to the original version.
It's just release notes, and it's potentially a huge benefit to the
customer. I'm not sure why they'd ever want to see the original version of
the release notes, but if they really needed to, they'd still have access
to them.
If not everyone gets the updated info because they made copies of the repo
too soon, that's probably okay. It's just like running into a bug because
you didn't wait for the next SRU or whatever.
What I'd like to see, however, is for all release notes to have a unique
tag that we can plug into a known URL base (like sun.com/msg was, or like
bugids are) and get the latest text. Connected systems can do this
automatically, and admins operating on disconnected systems can be sure to
do it manually, as part of paying the cost for running a disconnected
system.
I'm with Danek here. As much as I advocate for repeatability, this is a
point on which it seems less important.
Dave
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
