On Mon, Jun 16, 2008 at 12:34:12AM +0100, John Levon wrote: > On Sat, Jun 14, 2008 at 07:02:47AM +0530, Venky wrote: > > > > >> If the publisher of A decides that [EMAIL PROTECTED] will not be > > > >> completely > > > >> compatible w/ previous releases, s/he has several choices > > > >> depending on the nature of that incompatibility. > > > >> > > > >> 1) if the incompatibility is with his own older packages, he can > > > >> simply require a minimum optional dependency on the newer version. > > > >> Eg, if [EMAIL PROTECTED] depended on [EMAIL PROTECTED], but [EMAIL > > > >> PROTECTED] doesn't satisfy [EMAIL PROTECTED]'s requirements > > > >> but does satisfy [EMAIL PROTECTED]'s, he can add a optional dependency > > > >> to [EMAIL PROTECTED] on [EMAIL PROTECTED]; > > > >> thus if B is installed w/ [EMAIL PROTECTED], it must be at [EMAIL > > > >> PROTECTED] or higher. > > > > > > > > Ah, that makes sense. What about when A's publisher has no idea what > > > > "B"s exist (let's say (A)pache)? Will there be a way to say "ALL B's > > > > that are dependent on [EMAIL PROTECTED] must be upgraded? > > > > > > An even more pernicious problem is when A's publisher doesn't know B > > > exists, > > > and thus has no idea about compatibility problems... > > > > > > We're still thinking about these aspects of the problem.... > > > > Traditionally handled by a "<=" constraint. In this case, [EMAIL > > PROTECTED] would > > depend on a version of A <= 1. When [EMAIL PROTECTED] is published, it > > will not > > get pulled in by consumers of package B until the maintainer of > > B certifies it with [EMAIL PROTECTED] and published a new package [EMAIL > > PROTECTED] with > > a constraint on A's version being <= 2. > > B cannot know to use such a constraint in the first place, so this will > not help. See earlier in the thread.
You mean B would not know that the next version of A is going to make an incompatible change to the interface? True, this would not help in that case unless B has set up preemptive constraints. For example, [EMAIL PROTECTED] could have a dependency of type depend type=incorporation fmri=pkg:/[EMAIL PROTECTED] This might make sense for packages which are closely coupled, like in your case. Does not make much sense for cases where generic interfaces are being provided (libdb.so, for example). The approach of having the add-on package having a circular optional dependency on the base package version seems clumsy. And like Bart mentioned, would not work in case where interface providers are not aware of every possible consumer. Being able to accommodate multiple incompatible version streams of packages would seem to be a cleaner way to handle this, as discussed here: http://groups.google.com/group/pkg-discuss/t/dbec2122f54a7fae With that approach, I would expect [EMAIL PROTECTED] to be published in a different "slot" (to user portage's terminology) from [EMAIL PROTECTED] This would be much better than coming up with a new package name for the incompatible version and breaking dependencies. Venky. -- One hundred thousand lemmings can't be wrong. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
