On Mon, Jun 16, 2008 at 07:39:29AM +0530, Venky wrote:
> 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]
Sorry, that was meant to read:
[EMAIL PROTECTED] could have a dependency of type
[EMAIL PROTECTED] depends on glassfish version < 5
You could do something similar with an incorporation:
depend type=incorporation fmri=pkg:/[EMAIL PROTECTED]
However, this would allow glassfish-user to be installed without
having the glassfish package installed.
Venky.
>
> 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
