* Peter Tribble <[EMAIL PROTECTED]> [2008-05-25 15:11]: > On Sat, May 24, 2008 at 1:18 AM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > > > 3. Equivalency. Peter T asked "Are you saying that you expect any > > two packages with the same unqualified name to be > > interchangeable?" Yes, this is the restriction; it allows a > > system to have a mix of sufficiently equivalent components from > > multiple publishers. Luckily, Mike G give us an example question > > to work through: > > > > Suppose apache.org published the exact same ant release as: > > > > pkg://opensolaris.org/vendor/apache.org/ant > > pkg://blastwave.org/vendor/apache.org/ant > > pkg://apache.org/devtools/ant > > > > Is there any way to for a consumer system to understand that > > they are equivalent for the purpose of dependency mapping? > > > > In the scheme we're proposing, the first two would be > > equivalent--and expected to deliver components to the same > > location. > > Are they equivalent? I would expect them to be different - I would (at > the very least) expect the opensolaris.org one to deliver its bits into > /usr, and the blastwave one to deliver into /opt/csw. > > And if I published my own ant package, it would (and very deliberately > so) deliver its bits somewhere different from the one from my OS vendor. > > > The third would not be, because "devtools/ant" and > > "ant" aren't the same. (See vendor/ namespace below.) > > So what about > > pkg://apache.org/ant > > or the "automated nethack timebomb" package at > > pkg://my.own.repository/vendor/foogames.com/ant > > In the absence of a centralized registry, unqualified names are > simply unsafe. (The current scheme with the stock ticker fiction > uses qualified names all the time.) > > That's not to say that user interfaces can't display the unqualified > names; that's less of a problem because the interface is capable > of supplying more context to differentiate alternatives.
Perhaps reusing the blastwave.org example was not the best choice. Let's restate the example as 1. pkg://a.org/vendor/c.org/ant 2. pkg://b.org/vendor/c.org/ant 3. pkg://c.org/devtools/ant 1 and 2 both have stem "/vendor/c.org/ant". They are expected to be equivalent, in that either would satisfy a dependency on pkg:/vendor/c.org/ant. 3 has stem "/devtools/ant", and is not equivalent. pkg://c.org/ant would only be equivalent if we decide that the vendor/ mapping I mentioned is sensible. Your example > pkg://my.own.repository/vendor/foogames.com/ant matches none of the stems discussed so far, and would not be treated as equivalent to any of them. It is easy to carve out separate space; the current proposal already has that in place. The question is whether or not we can also have a shared space where component substitution becomes possible. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
