Hi Brock,
Thanks for more information on uses scenarios.
Reading from what you are saying, the pkg freeze/unfreeze commands are
client side only operations.
By this I meant, when I ran the command
pkg freeze <fmri>
on my machine that freeze only applied to that particular BE, is that
correct?
That is, user can revert back to previous stage when a unfreeze is
carried out.
will freeze operation freezes packages and its underlying stack?
Eg. If I freeze firefox, will it freeze the version of gtk+/glib it uses?
Thanks,
-Ghee
On 05/26/11 21:17, Brock Pytlik wrote:
On 05/26/11 01:49, Ghee Teo wrote:
Under what circumstances/scenarios do one need these features?
Are these scenarios be used much in practice?
If it is not, is it worthwhile to create features that is not ever
been used?
My personal experience is that IPS is pretty well constraints
controlled through its incorporation mechanism. Putting another layer
of constraint on top really complicated the conceptual model for the
make the developer and the administrator.
IPS does an excellent job of ensuring that packages more together.
What it currently has no easy way to do is to allow a USER to express
their desire to hold one or more packages at their current versions.
(While a user could publish their own incorporation package and then
remember to uninstall it when they want to move that package forward,
that's not exactly a friendly UI.) What circumstances/scenarios would
I need these features? Well, suppose I want to move forward to the
next update of Solaris, except I've heard that the next version of X
(where X is some userland component) is really buggy, or disables a
feature I critically rely upon, or just hasn't been certified for my
business process, even though the Solaris kernel (as an example)
contained in that update, is something I want/need.
Do I expect every user to use pkg freeze? No. Do I think it provides a
capability that's important to a segment of our users? Absolutely. If
a user doesn't want to use it, will it ever get in their way? Not that
I can see.
I hope that explains the reason we're adding such a capability. Please
let me know if you have other or better ways to provide this
functionality, or if you still think it's unneeded.
Brock
-Ghee
On 05/25/11 10:27 PM, Brock Pytlik wrote:
Greetings all,
I'm going to try and pick up pkg freeze. While we've talked about it
in general, if there's a bug or writeup of the feature in detail,
I've not been able to find it. I'm sending this out so we can try to
nail down naming and UI issues before the implementation gets too
far along.
Proposed commands:
pkg freeze (fmri|pattern|pkg_name) ...
pkg unfreeze pkg_name|pattern ...
--------------------------------
Are we happy with freeze/unfreeze or should it be freeze/thaw,
freeze/melt, freeze/boil, constrain/unconstrain, constrain/free,
constrain/relax, etc...?
Freezing a package means that only versions of that package which
match the pattern with which the package was frozen can be installed
or upgraded. More detail for this is below.
Unfreezing a package removes the constraint which pkg freeze place
on the package's movement.
Proposed uses:
1) action: User types 'pkg freeze <fully_specified_fmri>' and that
version of the package is installed
result: That package can't move because it's been frozen down to the
time stamp.
return code: 0
2) action: User types 'pkg freeze <fully_specified_fmri>' and that
version of the package isn't installed, but is known
result: Only that version of the package package, including
timestamp, can be installed.
return code: 0
3) action: User types 'pkg freeze <fully_specified_fmri>' and that
version of the package isn't installed, and isn't known
result: Error? I can see this either being treated as situation 2 is
in which case no version of the package could be installed.
return code: 1? (otherwise 0)
4) action: User types 'pkg freeze pkg://pub1/<fmri|pattern|pkg_name>'
result: Unknown. Can packages be frozen to a publisher? (regardless
of whether a pkg_name, pattern, or fmri is used)
return code: Unknown
5) action: User types 'pkg freeze example_pkg' and 'example_pkg' is
installed.
result: example_pkg is frozen at the installed version down to its
timestamp.
return code: 0
6) action: User types 'pkg freeze example_pkg' and 'example_pkg' is
not installed.
result: Error is reported to the user
return code: 1
7) action: User types 'pkg freeze '*''
result: Every package installed on the system is frozen at the
version it's installed, down to timestamp
return code: 0
8) action: User types 'pkg freeze [email protected]' and
example_pkg is installed with a matching version
result: Only versions of [email protected].* are allowed to be
installed or upgraded to. This is equivalent to having an
incorporate dependency on [email protected].
return code: 0
9) action: User types 'pkg freeze [email protected]' and
example_pkg is not installed.
result: Only versions of [email protected].* are allowed to be
installed. This is equivalent to having an incorporate dependency on
[email protected].
return code: 0
10) action: User types 'pkg freeze [email protected]' and
example_pkg is installed but at 166 or 164.
result: Error
return code: 1
11) action: User enters 2 or more packages to be frozen, but only
some of them can be frozen as specified.
result: Error and no packages are frozen.
return code: 1
12) action: User types 'pkg unfreeze pkg_name' and that package is
frozen at any version.
result: The package is no longer frozen.
return code: 0
13) action: User types 'pkg unfreeze (fmri|pattern|pkg_name)' and
that package is not frozen.
result: Message stating the package wasn't frozen
return code: 4 (EXIT_NOP)
14) action: User types 'pkg unfreeze "*"' and at least one package
is frozen
result: All packages are unfrozen
return code: 0
15) action: User types 'pkg unfreeze "*"' and no packages are frozen
result: User is messaged that no packages were frozen, so none could
be unfrozen
return code: 4 (EXIT_NOP)
Open questions:
1) Can freeze be used to freeze a package to a publisher? If not, is
including a publisher in the fmri to freeze an automatic error?
2) Can a user freeze the build release (ie, the 5.11 part of our
fmris)? When freezing down to the timestamp is the build release
allowed to be present? Must it be present?
3) Can freeze only take package names? It would simplify the matrix
for testing. I can't think of a use case for needing to unfreeze a
package, but only if it's been frozen at a particular version.
4) Whether a package is currently frozen has no effect on what 'pkg
freeze' on that package does, the new restriction always replaces
the older if it's valid.
If we decide that we need pkg unfreeze to take versioned arguments,
here are some more use cases:
1) action: User types 'pkg unfreeze <full_specified_fmri>' and that
package is frozen at that exact timestamp.
result: The package is no longer frozen.
return code: 0
2) action: User types 'pkg unfreeze <full_specified_fmri>' and that
package is frozen, but not at that exact timestamp.
result: Error
return code: 1
3) action: User types 'pkg unfreeze example_pkg@1' and that package
is frozen at example_pkg@1, [email protected], or any other more
specific version.
result: The package is no longer frozen
return code: 0
4) action: User types 'pkg unfreeze example_pkg@1' and that package
is frozen, but not at that version
result: Error
return code: 1
I've tried to cover the relevant situations, but it's certainly
possible that I've missed some. Let me know what you think.
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
