On Jun 22, 2009, at 12:34 PM, Danek Duvall wrote:
Comments and critiques appreciated. Substantive ones requested by COB
Wednesday.
=
=
=
=
=
======================================================================
Introduction and Motivation
---------------------------
An obsolete package is a version of a package which no longer
delivers any
meaningful content, compared to previous versions. Marking a package
obsolete indicates that a repo is no longer in the business of
delivering
any bits under that name.
Because obsoletion is connected to a version, and each published
version
can either be obsolete or not, it means that technically a package
cannot
be obsolete, but a package version can be. When noting that a package
(package stem) is obsolete, a version or version range must be
associated
with that information.
Later on, you mention that the way to perform an obsoletion is to
publish a new version of a package with the 'obsolete' tag. How does
that fit with a 'version range'? I feel as though I've missed
something.
Also, does this proposed obsoletion functionality touch on another,
similar need we have for removing 'toxic' packages from a repository
(i.e. legal requirement, etc.)?
...
Mechanism
---------
In the spirit of allowing the catalog to be merely a cache of data
stored
in the manifest, a package will be marked obsolete by setting the
package
attribute "pkg.obsolete" to "true" in the package manifest. This
action
may be filtered by a variant tag.
However, since many of the operations that will need to know about the
obsolete state of a package shouldn't have to parse many manifests
to get
at it, this state should be maintained in the catalog as well. This
implies that the publication server will need to parse the manifest
more
intelligently than it does currently in order to extract this
information.
No change to the catalog format or to the /catalog operation is
required.
Instead of a "V" tag for an FMRI, an obsolete package version will be
marked as "O". The upcoming key/value-pair based catalog format
should be
able to handle obsolete package simply as well, likely tagging the
fmri
with "obsolete=true" just as in the manifest.
So then, an obsolete tag for a package that does not specify a
variant, that contains one or more variants, is deemed to apply to all
variants?
...
Behavior
--------
In the simple case, where a package is obsoleted without an associated
rename, and nothing on the system depends on it, the package will be
uninstalled on upgrade, and on initial install will emit a message,
but not
fail the installation.
By upgrade, that means as a result of 'pkg install' and 'image-update'
when a prior, non-obsolete version is installed, correct?
...
Publication Changes
-------------------
As mentioned above, the obsolete attribute will need to make its way
into
the catalog, so the publication server code will need to parse the
manifest
looking for this attribute. Given the upcoming catalog format changes
putting dependency information into the catalog, this won't present
any
extra burden on publication.
Given the problems with depending on an obsolete package, the server
should
not allow such dependencies. This should be thought of as a distro-
wide
(or at least repo-wide) flag day. In the case that a package is being
renamed, the dependent packages should be changing their depend
actions to
match the new name, and in the case that a package is simply being
EOLed,
any other package depending on it should simply be treated as a bug.
- server should expand dependencies to unambiguous stems (or fail
add?)
- the server might want to refuse publication of an obsolete package
with
adjacent versions (no non-obsolete version "in between")
Currently, this could cause issues with the republication mechanism
used by pkgrecv. However, since it is already known that the current
mechanism for pkgrecv is not viable long-term, this may not matter.
But, that may mean that this restriction either has to be optional
from an api perspective, or that the republication mechanism used by
pkgrecv will have to be re-implemented first before this restriction
is put into place.
OpenSolaris Operational Changes
-------------------------------
re-publication of obsolete packages, inclusion in entire, etc.
Currently, we clear out a package's import file on obsoletion,
leaving a
comment behind explaining what we've done and why. This will be
replaced
by adding a new keyword for solaris.py to interpret: obsolete. It
will
take no arguments, and it simply adds "set name=pkg.obsolete
value=true" to
the manifest, while allowing only other set actions and depend
statements
to be added. Note that because it won't be importing any SVr4
packages, we
will have to add by hand the metadata that would otherwise have been
populated from the pkginfo file (summary, description).
We also republish the empty packages each version after they've been
emptied. There's no particular reason for that now, and we should
definitely stop when we're publishing properly obsolete packages.
In addition, obsolete packages should not, generally, be constrained
by
entire or any other large-scale incorporations. Doing so would be
rather
unfriendly:
- if an unbundled package A depends on a WOS package B which gets
obsoleted in build X, then upgrading through build X would fail
due to
this constraint (because A would no longer have its dependency
satisfied). Without the constraint, it would be allowed for the
system
to stay on the latest non-obsolete version of the package (or at
least
the one that was already installed on the system), which is probably
what the user wants. This wouldn't be the normal course, at least
from
the first -- since package B is now unconstrained, it will be
upgraded
to the latest, obsolete version, and so be removed anyway, but the
system could be enhanced later to allow it to remain on the system.
This seems problematic if a package later becomes un-obsoleted, since
the builds for which that package was obsolete won't have any
restrictions on which version of that package they can install if
there is a newer one available. It seems then, that if a package is
un-obsoleted, that we would have to re-publish entire for each of the
builds for which a package was originally obsolete.
- If a leaf package got EOLed, a user might be annoyed that it was
removed from the system -- perhaps they'd rather keep the latest (or
installed) version around.
Perhaps the long-term solution is to integrate with freezes such that,
based on policy, we automatically freeze the existing, installed
version of a package instead of uninstalling it because the newer
version is obsolete?
...
Test Cases
----------
Legend:
0 No package (transition from/to implies install/uninstall)
-> transition
A package "A"
Ao obsolete package "A"
A' new version of package "A"
A (-> B) A depends on B
A (<- B) B depends on A
...
11 install an ambiguous name where only one match is non-obsolete
???
12 upgrade a package to an obsolete version with a dependency on a
package
which has a (potentially) ambiguous name
???
...
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
