* Peter Tribble <[EMAIL PROTECTED]> [2008-05-29 20:14]: > On Wed, May 28, 2008 at 12:26 AM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > > > 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. > > Why would I expect that?
That's what this naming proposal allows you to expect. > Why have a.org and b.org created a new package rather than simply using the > original package? The only answer is that it is in some way different. And you > have no idea from the name what differences exist, so it's clearly impossible > to make any statements about equivalence. From the name, yes. The expectation is that, if a second publisher uses the same name for a package as the original publisher, there is some documented statement about equivalence (or differences). An example would be a library presenting the same public/private APIs, but produced with alternate tools or with differing flags. Another would be an experimental kernel with some alternate private algorithm. Each of these would be equivalent, in the sense that dependent packages would still operate correctly; equivalence does not imply identical behaviour, however. > My understanding here is that the interpretation of > > pkg://a.org/vendor/c.org/ant > > Is that vendor c.org has created a piece of software "ant", and that this > particular package is created by distributor a.org. This isn't a case of > a.org providing a mirror copy out of their repository (in that case, the > package name doesn't contain a.org); a.org have rebuilt/modified/repackaged > or whatever the software and have done something to it that causes > it to be published under their authority rather than somebody else's. No. The vendor/ namespace *is* the republishing of someone else's (c.org) package in your (a.org) namespace. > > 3 has stem "/devtools/ant", and is not > > equivalent. > > This gets even more confusing. One might expect that package 3, being > the one direct from the vendor, would be the master package to which > others defer. (Or perhaps the other authorities need to add the /devtools > element to the name?) That's an assumption about upstream participation that's not part of this proposal. > > 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. > > OK, so the /vendor/c.org part of the name serves to ensure that different > things that happen have the same name, or different implementations of > the same thing, get different names. > > So that > > /vendor/gnu.org/make > > refers to gnu make, while > > /vendor/sun.com/make > > refers to the Sun make. > > With this interpretation, you can't draw any conclusions about where it's > going to be installed, what the command might be called, or even how > it was compiled - merely that you're talking about one vendor's make > application as opposed to another. I don't think that makes (which are sometimes interchangeable and often not) are a good choice to illustrate this, but yes, the package name answers none of these questions. However, you can conclude that pkg://a.org/my-command and pkg://b.org/my-command means that b.org is doing its best to present a set of components that could be substituted for a.org's version--which implies same install locations, etc.. Whether or not you trust b.org (or a.org) to produce such a component is where the need for signed manifests and catalogs (so that you know b.org is in fact b.org) becomes relevant. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
