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
