Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman <rich0@gentoo.org>]

On Mon, Feb 8, 2016 at 12:01 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> On 08/02/16 11:18 AM, Rich Freeman wrote:
>>
>> It seems like this should just be another step in the handbook -
>> pick your desired device manager.
>>
>> This just seems more like the Gentoo way, and it completely
>> sidesteps all the controversy over defaults.  We're already
>> working on fixing the few remaining functions.sh references so
>> that openrc can be removed from the system set as well.
>>
> I thought the point of this discussion had to do mostly with what
> udev variant gets installed when a user doesn't specify one.  And
> AFAIK, since there are still plenty of packages that *DEPEND on
> virtual/udev , the discussion's still worth having isn't it?

Sure, but if you've already picked which one you want as your default
at install time, then you won't have one pulled in as a default.  If a
package does pull in the virtual and you didn't want it installed at
boot, chances are the package won't work anyway, or the dependency
probably shouldn't be there.

But, if we want to change the default it sounds like the main criteria are:
* lots of distros using it by default
* feature parity with udev
* encouraged by its upstream as installed

Sounds like systemd is the obvious default.  :)

Oh wait, I left one out:
* being an in-house fork

Well, I suppose I could just git clone systemd from a month ago and
occasionally cherry-pick commits from upstream and stick that in the
tree.  Maybe I'll rename systemd-nspawn back to nspawn to add some
distinctiveness.  Then we can say that we're eating our own dogfood.

And this is why I think it is better to sidestep these sorts of
debates and just stick the instructions in the handbook.  I don't
really care which is listed first - heck, we still don't have dracut
in there and I don't get why anybody would install a system without
that.  (Another weekend project to do, along with integrating and
simplifying the systemd install instructions...)

-- 
Rich