On 02/05/10 12:53, [email protected] wrote:
On Fri, Feb 05, 2010 at 12:38:17PM -0800, Garrett D'Amore wrote:
On 02/ 5/10 12:30 PM, [email protected] wrote:
On Fri, Feb 05, 2010 at 09:42:43AM -0800, [email protected] wrote:
The intent of the vendor subcomponent wasn't necessarily to capture the
vendor producing the chipsets but rather the one who owns the
specification.
That said, I'm certainly not wedded to keeping the vendor name there
particularly if others have related concerns.
What's our plan to cope with different vendors that deliver equivalent
drivers? It doesn't seem all that far fetched to have
driver/network/sun/e1000g and driver/network/intel/e1000g.
Isn't that handled by the (elided) supplier component of the package
name? I.e. as I understand the package name will actually be
opensolaris.org somesuch...
You're referring to the publisher. Based upon the namespace documents
that Stephen sent out a year or more ago, the name implies equivalence,
not the publisher. In that situation, any publisher delivering
driver/network/e1000g will be considered to be delivering an equivalent
package.
If this sounds like a recommendation to vendors to avoid shipping
unbundled binaries to "override" system supplied drivers.... well it
is!
We already have a mechanism that allows the client to determine a search
order when multiple publishers deliver equivalent packages. Unless the
user changes the default, the opensolaris.org publisher is considered
the preferred source for these binaries.
I was really trying to get Stephen or David to clarify the following:
a. Are we still following the guidelines from Stephen's namespace
documents?
b. If so, the namespace documents define a portion of the namspace that
each vendor is allowed to reserve for themselves. Do we want to
reccomend that vendors delivering their own versions of drivers, or
custom drivers, explicitly make use of that private namespace. E.g.
Intel/driver/network/e1000g. At least according to the namespace
documents that's not equivalent to driver/network/e1000g.
Two packages w/ different names must not deliver the same files, unless
at least one (preferably both) has an exclude dependency on the other.
Exclude dependencies are a pain, and can result in non-obvious problems
w/ upgrade.
- 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
