On Tue, Jun 23, 2009 at 04:02:26PM -0700, Bart Smaalders wrote: > >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....
Yes. As with all dependency analysis, it needs to be done in some context, and an incorporation is going to be the most appropriate here. > 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. You're right, thanks. I'm not sure, though, how the optional dependency is more error-prone. It seems cleaner to me, though obviously either one would do the trick. > 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? Dan had the same comment, and I would tend to agree. His (quite compelling) argument was that if you have two distinct states, we can do more error checking -- an explicit rename means we have to have dependencies, while an explicit EOF means we have to have no dependencies. As for a "reason" attribute, he also suggested that, and my answer was that once we have buglists published in each package, that would be the most appropriate way of marking that, I think. Unless there's some UI component that would want to spit out that level of detail (which seems a bit dubious to me). Thanks, Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
