On Mon, Jun 22, 2009 at 08:25:08PM -0500, Shawn Walker wrote: > >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.
Normally, the version range will be open-ended to the future. That is, a package can be last published non-obsolete at version 3, published obsolete at version 4, and that's it. However, packages may be resurrected (we had one do that just recently), so we might have the situation where the above package is published non-obsolete again at version 5. So the range here is (3, 5). Given that there might have been a version branch on 3.x, then you might have a non-obsolete package at 3.6, obsoleted at 3.7, putting the apparent range at (3.6, 5). I didn't mean for this to be a big thing; it's more that it falls out from the way we manage our version space, as well as the fact that resurrection is possible. > 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.)? There's a connection to toxic (and historical as well), but I decided to leave that out. The difference between obsolete and toxic is that marking a package toxic is an operation on an existing version of a package, rather than introducing a new version. The existing version needs to be marked, because it needs to be physically yanked (potentially, at least) from the repo. > 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? Yes. Though as Dan pointed out to me yesterday, we probably won't be able to implement variant-specific obsolete until we have the new catalog format. > >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? Yes. > >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. I'm guessing that the problem here is that pkgrecv may not publish packages in any guaranteed order, thus possibly publishing two "adjacent" obsolete versions even though a non-obsolete version may be published in between them a bit later? > >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. True. Though with backtracking, this won't be a real problem -- if the package can't be installed because of its dependencies, then it won't be, and otherwise, it can. And it won't be installed automatically on resurrection, which should lessen the impact even further. (Though Dan suggested that we might want that, if the user had explicitly installed it previously. This would require client-side intent.) > >- 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? Sure. > >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 > > ??? Is the confusion about what "ambiguous name" means? That's the first specific example: what do you do when you've packages named "netbeans" and "developer/netbeans" and you ask to install "netbeans"? These cases say "use the non-obsolete one, if precisely one such exists". Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
