2008/5/25 Peter Tribble <[EMAIL PROTECTED]>: > 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.
Actually, I believe the intent here is that everything really does deliver its bits into the same place. As the person installing the packages, if you want them to install into /opt/csw instead, you would just do: pkg image-create -F -a authname=http://blastwave.org /opt/csw Then: pkg -R /opt/csw install ant As such, there's really no reason for the bits to deliver themselves into /opt/csw, etc. Some administrators are going to prefer having the isolated stack; but many users, I suspect, are going to want any packages they install to "integrate" with the rest of the system instead of living in an "isolated tree." Cheers, -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
