| 1 |
On Sat, Aug 8, 2020 at 6:57 PM William Hubbs <williamh@g.o> wrote: |
| 2 |
|
| 3 |
> Hi Rich, |
| 4 |
> |
| 5 |
> > William - can you actually elaborate on WHY you want to change things? |
| 6 |
> > Is there some problem with eudev? Is it actively maintained and |
| 7 |
> > generally tracking upstream udev commits (minus whatever they |
| 8 |
> > intentionally don't want to accept)? |
| 9 |
> |
| 10 |
> It is maintained primarily by one person the last time I checked, and I |
| 11 |
> don't really know what he has included or not included from udev. What |
| 12 |
> I can say is that the last release of eudev hit the tree a year ago, |
| 13 |
> and I'm not sure about feature parity with udev. |
| 14 |
> |
| 15 |
> > I'd be curious as to a list of the practical differences between the |
| 16 |
> > two at this point. For the longest time the only ones I was aware of |
| 17 |
> > were the de-bundled build system, and the change in the default |
| 18 |
> > persistent ethernet device name rule which was made in udev but not |
| 19 |
> > made (by default) in eudev. Perhaps at this point there are other |
| 20 |
> > differences. |
| 21 |
> |
| 22 |
> The only other one I know of is if you aren't using glibc udev will not |
| 23 |
> compile, but I'm not even sure that is an issue still. |
| 24 |
> |
| 25 |
> The way I see it, we switched away from udev because of a fear that |
| 26 |
> never materialized, and I'm not convinced that we have enough time to |
| 27 |
> keep it in feature parity with udev which it needs to be to be the |
| 28 |
> default provider. |
| 29 |
|
| 30 |
|
| 31 |
Name the missing features in eudev. |
Archives