Shawn Walker wrote:
Brock Pytlik wrote:
Shawn Walker wrote:
Before this work is done, image versioning need to be implemented.
The changes you've proposed within are essentially a change in image
format and that means that older clients attempting to manipulate an
image created by a newer client won't work quite right or will cause
loss of this additional information.
I don't think I agree that this work should be stalled by image
versioning. Clients without versioning information will plow ahead
regardless and there's nothing we can do about it. Essentially, all this
Right, but since we know that image versioning is an issue, and we may
have to revise this proposed functionality soon after putback, it
seems logical to me to have a versioning framework in place to make it
less painful wherever possible.
To me its an issue of priorities, and we disagree on the priorities of
these two things.
would effect is that the set of clients which exist post versioning
put back and pre-user-intent would function correctly. If this goes
back first, that set doesn't exist and thus (by fiat) functions
correctly.
That isn't necessarily true, notably in the case of user images.
You'll have to explain how this isn't true.
Accept the precondition for the moment that development of image
versioning and user-intent happen on independent schedules. If image
versioning lands at time N. All clients prior to time N will continue to
modify images they "shouldn't." If user intent lands at time N+M, it
will continue to have issues with the set of clients from time <N. If
user intent lands at time N-M, clients from time <N-M will cause problems.
If others agree that this should stall on that, I'll wait for such a
scheme to integrate, but I don't believe it's necessary to do so. I
think user-intent is a clear win for a large class of users based on
what it will allow us to improve in terms of UI. (I intend to pick up
the group package uninstall once this goes back for examples.) I
think the class of users using multiple versions of pkg to manage is
a tiny set of users. Given that I don't see this introducing a
significant issue for those users, I'm not inclined to hold this work
up.
I'm not arguing that this isn't a huge win, but I think image
versioning is a very important bit of functionality that will
ultimately help, not hinder the work proposed here.
I disagree. I think image versioning is nice to have, but in any case,
if the format changes, the code will have to know how to read the old
format. Whether it's told to read the old format by an image version
number or by finding an expect file isn't there doesn't seem to make
much of a difference for the complexity of the code.
As far as I can see, the compelling case for image versioning is
multiple pkg's at different versions modifying the same image. I assert
(admittedly without evidence beyond my own perceptions) that this is the
rare case, both as measured by users and by actions performed on an image.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
