On Wed 12 Aug 2009 at 09:34PM, Danek Duvall wrote:
> So here's my first cut at solving the problem:
>
> http://cr.opensolaris.org/~dduvall/pkg-bug10630/
>
> If anyone still wants to bicker over the behavior, let's hear it. Also,
> suggestions on better language is welcome.
>
> Here's the sample output. This represents installing three versions of the
> same package, where the first version simply delivers /etc/driver_aliases
> with 'danek "pci8086,1234"' in it and no driver actions, the second version
> delivers an updated driver_aliases file that replaces "danek" with "zigit",
> and adds a "zigit" driver action with "pci8086,1234" as an alias, and the
> third version delivers the same aliases file and the same "zigit" driver,
> but also a "figit" driver action which is otherwise identical to the
> "zigit" action.
>
...
>
> The 'zigit' driver shares an alias with the 'danek' driver, but
> the system cannot determine how the latter was delivered. Its entry
> on line 1 in /etc/driver_aliases has been commented out. If
> this driver is no longer needed, it may be removed by invoking
> 'rem_drv danek' as well as removing line 1 from /etc/driver_aliases.
This seems mostly sane to me, although I have some comments.
Consider a driver on the system--
'audiohomebrew' with three aliases, 'a', 'b', and 'c'.
Perhaps the user installed this from source code, or a svr4 pkg.
Now, let's assume that OpenSolaris eventually writes a different
driver for this same device:
'audioopensolaris' with two aliases, 'a' and 'c'.
So I think one issue is that we'll print the message above twice, with no
indication of the alias names, although we do print the line number. Since we
have the alias name, should we print it?
The other issue is that we won't wind up completely disabling 'audiohomebrew' in
this scheme... Should we disable drivers who have aliases in conflict with our
driver? Probably too heavy handed.
When commenting out lines, I would say that the general best practice is to
leave behind an indicator of "who did it" as a one line comment.
Otherwise the code looks fine.
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss