Moving from old udev to eudev

classic Classic list List threaded Threaded
108 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
> True, it won't be dropped for long as people are maintaining it. That's
> how maintainership works.
> But trying to lie to people it's somehow solving something currently is
> annoying as 'ell and should be corrected where seen.

It is solving the problem of *when* (not if - if the words I have read
from the systemd maintainers can be taken at face value) the systemd
maintainers decide to pull the plug on the ability to have a
systemd-less udev...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alon Bar-Lev-2
On Mon, Aug 12, 2013 at 3:17 PM, Tanstaafl <[hidden email]> wrote:

>
> On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
>>
>> True, it won't be dropped for long as people are maintaining it. That's
>> how maintainership works.
>> But trying to lie to people it's somehow solving something currently is
>> annoying as 'ell and should be corrected where seen.
>
>
> It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev...
>

Correct. And because that we endorse it.
Look what happened with the logind.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by tanstaafl-2
On 12/08/13 15:17, Tanstaafl wrote:

> On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
>> True, it won't be dropped for long as people are maintaining it. That's
>> how maintainership works.
>> But trying to lie to people it's somehow solving something currently is
>> annoying as 'ell and should be corrected where seen.
>
> It is solving the problem of *when* (not if - if the words I have read
> from the systemd maintainers can be taken at face value) the systemd
> maintainers decide to pull the plug on the ability to have a
> systemd-less udev...
>

Then we will carry a minimal patchset on top of sys-fs/udev that will
keep it working without systemd for long as it's sustainable.
And at this point it's pointless to talk of forking yet, it should be
done only when it's required.

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by Alon Bar-Lev-2
On 12/08/13 15:19, Alon Bar-Lev wrote:

> On Mon, Aug 12, 2013 at 3:17 PM, Tanstaafl <[hidden email]> wrote:
>>
>> On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
>>>
>>> True, it won't be dropped for long as people are maintaining it. That's
>>> how maintainership works.
>>> But trying to lie to people it's somehow solving something currently is
>>> annoying as 'ell and should be corrected where seen.
>>
>>
>> It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev...
>>
>
> Correct. And because that we endorse it.
> Look what happened with the logind.

They made it clear from the start that logind is not going to work for
non-systemd and that Ubuntu is doing something utter crazy.
We were going to ride with that horse at the expense of Ubuntu folks for
a while, but dropped the effort as futile. Now Ubuntu is stuck at
logind-204 and it's unclear what will they do next.
Don't try to twist it into anything it's not, it's not comparable w/ udev.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alon Bar-Lev-2
In reply to this post by Samuli Suominen-4
On Mon, Aug 12, 2013 at 3:33 PM, Samuli Suominen <[hidden email]> wrote:

> On 12/08/13 15:17, Tanstaafl wrote:
>>
>> On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
>>>
>>> True, it won't be dropped for long as people are maintaining it. That's
>>> how maintainership works.
>>> But trying to lie to people it's somehow solving something currently is
>>> annoying as 'ell and should be corrected where seen.
>>
>>
>> It is solving the problem of *when* (not if - if the words I have read
>> from the systemd maintainers can be taken at face value) the systemd
>> maintainers decide to pull the plug on the ability to have a
>> systemd-less udev...
>>
>
> Then we will carry a minimal patchset on top of sys-fs/udev that will keep
> it working without systemd for long as it's sustainable.
> And at this point it's pointless to talk of forking yet, it should be done
> only when it's required.

It is done ahead so it won't be too late, as you say... eudev is
"minimal patch set" over systemd.

Someone should have forked the logind as well ahead, so the whole
gmone discussion was irrelevant.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 12/08/13 15:38, Alon Bar-Lev wrote:

> On Mon, Aug 12, 2013 at 3:33 PM, Samuli Suominen <[hidden email]> wrote:
>> On 12/08/13 15:17, Tanstaafl wrote:
>>>
>>> On 2013-08-12 8:06 AM, Samuli Suominen <[hidden email]> wrote:
>>>>
>>>> True, it won't be dropped for long as people are maintaining it. That's
>>>> how maintainership works.
>>>> But trying to lie to people it's somehow solving something currently is
>>>> annoying as 'ell and should be corrected where seen.
>>>
>>>
>>> It is solving the problem of *when* (not if - if the words I have read
>>> from the systemd maintainers can be taken at face value) the systemd
>>> maintainers decide to pull the plug on the ability to have a
>>> systemd-less udev...
>>>
>>
>> Then we will carry a minimal patchset on top of sys-fs/udev that will keep
>> it working without systemd for long as it's sustainable.
>> And at this point it's pointless to talk of forking yet, it should be done
>> only when it's required.
>
> It is done ahead so it won't be too late, as you say... eudev is
> "minimal patch set" over systemd.
>
> Someone should have forked the logind as well ahead, so the whole
> gmone discussion was irrelevant.
>

It's not too late to fork logind in anyway, it's down to 204 in git and
then review commits from there up to current w/ the required patches
Ubuntu carries for non-systemd operation (yes, logind from 204 never
worked without patching either but the patches were just a lot less than
what 206 would need).
But nobody has been willing to do the work. It was propably for the best
we didn't ever adopt it at all since it's not sane to package software
you can't then keep maintained.

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

hasufell
In reply to this post by Samuli Suominen-4
On 08/12/2013 02:06 PM, Samuli Suominen wrote:

> On 12/08/13 14:37, hasufell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/02/2013 05:01 AM, Samuli Suominen wrote:
>>> On 02/08/13 05:48, Dale wrote:
>>>> Samuli Suominen wrote:
>>>>>
>>>>> Huh? USE="firmware-loader" is optional and enabled by default
>>>>> in sys-fs/udev Futhermore predictable network interface names
>>>>> work as designed, not a single valid bug filed about them.
>>>>>
>>>>> Stop spreading FUD.
>>>>>
>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>> sys-apps/module-init-tools already was removed as unnecessary
>>>>> later on.
>>>>
>>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>>> spreading FUD instead of others.  Like others have said, udev was
>>>> going to cause issues, eudev has yet to cause any.
>>>
>>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>>> doesn't bring in anything useful, and it reintroduced old bugs from
>>> old version of udev, as well as adds confusing to users. And no,
>>> sys-fs/udev doesn't have issues, in fact, less than what
>>> sys-fs/eudev has. Like said earlier, the bugs assigned to
>>> [hidden email] apply also to sys-fs/eudev and they have even more in
>>> their github ticketing system. And sys-fs/udev maintainers have to
>>> constantly monitor sys-fs/eudev so it doesn't fall too much behind,
>>> which adds double work unnecessarily. They don't keep it up-to-date
>>> on their own without prodding.
>>>
>>> Really, this is how it has went right from the start and the double
>>> work and user confusion needs to stop.
>>>
>>> - Samuli
>>>
>>>
>>
>> * you are not telling the whole story about what happened and why the
>> fork came into life in the first place. It's not as simple as you seem
>
> True, I didn't mention people were needlessly unwilling to join the
> Gentoo udev team despite being invited to.

That's a bit unrelated. It wasn't just about the gentoo ebuild.

>
>> to suggest. There were good reasons at that point. Some changes were
>> merged by udev upstream and there are still more differences than you
>> point out. That has been discussed numerous of times.
>> * claiming that eudev didn't improve anything is wrong and can be proven
>
> I can easily prove eudev is nothing but udev and deleted code, plus
> restored broken 'rule generator', plus useless kept static nodes
> creation which was moved to kmod, plus needlessly changed code for
> uclibc support -- uclibc now has the functions udev needs.
>

Wonder why udev upstream merged back changes if it was all that bad.

>> * that eudev is behind udev most of the time is correct
>> * that it causes tons of breakage for users... well, I don't know, not
>> for me since almost the beginning
>> * eudev will not be treecleaned until the gentoo devs who maintain it
>> agree (at best, it may be masked) and even if eudev will be obsolete
>> at some point, then it has been a success
>> * I don't understand why you add those rants all over different
>> mailing lists. I have seen it numerous of times and your precision
>> about explaining the situation does not improve. If you think that
>> people need to be warned about eudev, then you should provide a reason
>> to mask it or drop it back to ~arch. Anything else is not constructive
>> and causes confusion.
>
> True, it won't be dropped for long as people are maintaining it. That's
> how maintainership works.
> But trying to lie to people it's somehow solving something currently is
> annoying as 'ell and should be corrected where seen.
>

Who lied?

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 12/08/13 16:39, hasufell wrote:

> On 08/12/2013 02:06 PM, Samuli Suominen wrote:
>> On 12/08/13 14:37, hasufell wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 08/02/2013 05:01 AM, Samuli Suominen wrote:
>>>> On 02/08/13 05:48, Dale wrote:
>>>>> Samuli Suominen wrote:
>>>>>>
>>>>>> Huh? USE="firmware-loader" is optional and enabled by default
>>>>>> in sys-fs/udev Futhermore predictable network interface names
>>>>>> work as designed, not a single valid bug filed about them.
>>>>>>
>>>>>> Stop spreading FUD.
>>>>>>
>>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>>> sys-apps/module-init-tools already was removed as unnecessary
>>>>>> later on.
>>>>>
>>>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>>>> spreading FUD instead of others.  Like others have said, udev was
>>>>> going to cause issues, eudev has yet to cause any.
>>>>
>>>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>>>> doesn't bring in anything useful, and it reintroduced old bugs from
>>>> old version of udev, as well as adds confusing to users. And no,
>>>> sys-fs/udev doesn't have issues, in fact, less than what
>>>> sys-fs/eudev has. Like said earlier, the bugs assigned to
>>>> [hidden email] apply also to sys-fs/eudev and they have even more in
>>>> their github ticketing system. And sys-fs/udev maintainers have to
>>>> constantly monitor sys-fs/eudev so it doesn't fall too much behind,
>>>> which adds double work unnecessarily. They don't keep it up-to-date
>>>> on their own without prodding.
>>>>
>>>> Really, this is how it has went right from the start and the double
>>>> work and user confusion needs to stop.
>>>>
>>>> - Samuli
>>>>
>>>>
>>>
>>> * you are not telling the whole story about what happened and why the
>>> fork came into life in the first place. It's not as simple as you seem
>>
>> True, I didn't mention people were needlessly unwilling to join the
>> Gentoo udev team despite being invited to.
>
> That's a bit unrelated. It wasn't just about the gentoo ebuild.

That's all it was.

>>> to suggest. There were good reasons at that point. Some changes were
>>> merged by udev upstream and there are still more differences than you
>>> point out. That has been discussed numerous of times.
>>> * claiming that eudev didn't improve anything is wrong and can be proven
>>
>> I can easily prove eudev is nothing but udev and deleted code, plus
>> restored broken 'rule generator', plus useless kept static nodes
>> creation which was moved to kmod, plus needlessly changed code for
>> uclibc support -- uclibc now has the functions udev needs.
>>
>
> Wonder why udev upstream merged back changes if it was all that bad.

Merged back what changes? That'd be news to me. I think you might be
confusing something.

>>> * that eudev is behind udev most of the time is correct
>>> * that it causes tons of breakage for users... well, I don't know, not
>>> for me since almost the beginning
>>> * eudev will not be treecleaned until the gentoo devs who maintain it
>>> agree (at best, it may be masked) and even if eudev will be obsolete
>>> at some point, then it has been a success
>>> * I don't understand why you add those rants all over different
>>> mailing lists. I have seen it numerous of times and your precision
>>> about explaining the situation does not improve. If you think that
>>> people need to be warned about eudev, then you should provide a reason
>>> to mask it or drop it back to ~arch. Anything else is not constructive
>>> and causes confusion.
>>
>> True, it won't be dropped for long as people are maintaining it. That's
>> how maintainership works.
>> But trying to lie to people it's somehow solving something currently is
>> annoying as 'ell and should be corrected where seen.
>>
>
> Who lied?

Let's rephrase lying with FUD for correctness.


1 ... 3456