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?

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.

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.

>  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?)

>  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.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to