John Levon wrote: > On Wed, May 14, 2008 at 03:34:46PM -0700, Bart Smaalders wrote: > >>> P.S. We are planning for introducing updates into the Glassfish V3 >>> repositories, some of which introduce incompatible change that require >>> multiple packages to be updated at the same time. I was hoping that we >>> could use incorporations to force the updates to happen in this way. >> Right now incorporations just specify a minimum dependency; this is a >> missing feature and will get fixed soon. > > (I found this old thread whilst trying to read up about how dependencies > are supposed to work.) > > When you say "will be fixed", do you mean "allow to specify a maximum > dependency", as the source seems to indicate, or something else? > > If it's the former, then I don't quite understand how incompatible > versioning is represented in pkg. For example: > > glassfish-user is released, depends on [EMAIL PROTECTED] > > [EMAIL PROTECTED] is released, not compatible > > If [EMAIL PROTECTED] can be upgraded into [EMAIL PROTECTED], then > glassfish-user > breaks (I'm presuming that at publication time that package has no idea > that [EMAIL PROTECTED] is going to be released). > > Probably the argument is that version 5 needs to be a separate package > instead, since it introduces incompatibilities? If so, how would the > system deal with things like "give me glassfish"? Some kind of > incorporation that matches either [EMAIL PROTECTED] or [EMAIL PROTECTED]
By fixed I meant that incorporations will not allow those package versions to change any portion of the specified version; eg depend type=incorporation fmri=pkg:/[EMAIL PROTECTED] means [EMAIL PROTECTED] and [EMAIL PROTECTED] are ok, but [EMAIL PROTECTED] and [EMAIL PROTECTED] are right out... A dependency of the type depend type=require fmri=pkg:/[EMAIL PROTECTED] means that [EMAIL PROTECTED] or greater is ok. 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. Alternatively, all these optional dependencies could appear in an incorporation that get installed on every image; this would allow distros to 'lock' their package versions together. Being packages, incorporations get versioned as well, of course... 2) If the new package [EMAIL PROTECTED] is just plain different than [EMAIL PROTECTED] - eg doesn't satisfy public dependencies, then changing the name of the package is likely to be the best approach. Note that this implies that either the [EMAIL PROTECTED] package doesn't collide in the filesystem w/ [EMAIL PROTECTED], or that other mechanisms such as an exclude type of dependency are needed. - 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
