Danek Duvall wrote:
Comments and critiques appreciated. Substantive ones requested by COB
Wednesday.
...
A well thought out set of ideas; thanks for tackling this!
Some comments:
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.
Clearly, packages being published against older builds must be allowed
to proceed, along w/ patches, etc. Perhaps a more statement might be
that packages published against a particular incorporation should not
depend on any obsolete packages in that incorporation....
In the case of an obsolete package undergoing a rename, it might make some
sense to constrain it, as if we decide to change the list of replacement
packages, making sure that the list is correct for any particular build (or
other grouping abstraction we might use) could use that mechanism.
However, if the obsolete package depended on specific versions of its
replacements, then those versions could be appropriately constrained.
It is in fact necessary to constrain renamed packages, either via entire
or by adding an optional dependency to the new package on the obsolete
version to prevent two packages (a pre-obsolescent version of the
original package, and the renamed package) from owning the same
files). The former is less work, and less subject to human error.
The case of a package depending on an obsolete package which itself has no
dependencies (ie, is EOLed) is more problematic. This means that the
functionality delivered by the obsoleted package has gone away entirely,
but another package is still presumably depending on that functionality.
In this case, the system should prevent either the upgrade to the obsolete
version of the package, or prevent the installation of the dependent
package (depending on the scenario at hand).
There appear to be two types of obsolescence here: a simple one
caused by rename/split, and a more complex one where we EOF the content.
These appear to cause different results and client behaviors; would
declaring these to be different explicitly be useful?
E.g.:
set name=pkg.obsolete value=true reason="rename"
set name=pkg.obsolete value=true reason="EOF"
or similar?
You could also articulate a finite set of package.states:
pkg.state=[obsolete,renamed,historical, ...]
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
