On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/11/2012 07:48 PM, William Hubbs wrote:
>> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
>>> How do you plan to handle the following:
>>> - foo installs an udev rule
>>> - install foo with old udev
>>> - upgrade udev
>>>
>>> are rules installed by foo used by new udev ?
>
>> No, they wouldn't be; that is a good reason to question the value of the
>> eclass itself. Maybe the correct way to do this is to forget the eclass
>> and just file bugs against packages that break having them move their
>> rules to the new location and set a dependency on the newer udev.
> Perhaps a new ebuild helper would be best here? It seems no one knows
> where to install udev rules in the first place (I know I didn't till a
> recent version of portage yelled at me with a QA warning).
>
> How about dorule/newrule?
I guess then we'd need the installed udev to set an environment variable
via /etc/env.d, in order to control the location where the rules are
installed?
--
Thanks,
Zac
07-12-2012, 03:03 AM
"Rick "Zero_Chaos" Farina"
rfc: udev-rules.eclass
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/11/2012 10:50 PM, Zac Medico wrote:
> On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/11/2012 07:48 PM, William Hubbs wrote:
>>> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
>>>> How do you plan to handle the following:
>>>> - foo installs an udev rule
>>>> - install foo with old udev
>>>> - upgrade udev
>>>>
>>>> are rules installed by foo used by new udev ?
>>
>>> No, they wouldn't be; that is a good reason to question the value of the
>>> eclass itself. Maybe the correct way to do this is to forget the eclass
>>> and just file bugs against packages that break having them move their
>>> rules to the new location and set a dependency on the newer udev.
>> Perhaps a new ebuild helper would be best here? It seems no one knows
>> where to install udev rules in the first place (I know I didn't till a
>> recent version of portage yelled at me with a QA warning).
>>
>> How about dorule/newrule?
>
> I guess then we'd need the installed udev to set an environment variable
> via /etc/env.d, in order to control the location where the rules are
> installed?
Oh I'm sorry, I didn't mean to sound like I had an actual implementation
idea in my head :-) I yield to those with greater experience on that,
but yeah, env makes some sense to me.
Thanks
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote:
> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
> > How do you plan to handle the following:
> > - foo installs an udev rule
> > - install foo with old udev
> > - upgrade udev
> >
> > are rules installed by foo used by new udev ?
>
> No, they wouldn't be; that is a good reason to question the value of the
> eclass itself. Maybe the correct way to do this is to forget the eclass
> and just file bugs against packages that break having them move their
> rules to the new location and set a dependency on the newer udev.
>
> This would have to be a rev bump for the broken packages.
>
> William
>
> >
> > A.
> >
So, does that mean the rule itself changes or just the location change
is needed?
If it is just a location change, a fairly simple udev-updater script
would do it. If the pkg needs to be re-compiled to work with/depend on
the new udev, then a more complex script would be needed. One more
along the line of python-updater/perl-cleaner.
--
Brian Dolbec <dolsen@gentoo.org>
07-12-2012, 05:01 AM
Ben de Groot
rfc: udev-rules.eclass
On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>> > I am about to release udev-186-r1, which will move everything currently
>> > in /lib/udev to /usr/lib/udev.
>>
>> Unless you're going to establish a symlink, please keep it under p.mask
>> until everything is using some common code — otherwise things _will_ break.
>
> Since multiple packages put things in /lib/udev, I'm not sure it is
> possible to establish a symlink from /lib/udev to /usr/lib/udev if
> that's what you mean; I'll look into it though.
Couldn't you, on udev upgrade, move everything in /lib/udev to
/usr/lib/udev, and then make the symlink? Seems fairly simple
to me, but maybe I'm overlooking something?
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
07-12-2012, 05:26 AM
Zac Medico
rfc: udev-rules.eclass
On 07/11/2012 10:01 PM, Ben de Groot wrote:
> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> wrote:
>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>>>> I am about to release udev-186-r1, which will move everything currently
>>>> in /lib/udev to /usr/lib/udev.
>>>
>>> Unless you're going to establish a symlink, please keep it under p.mask
>>> until everything is using some common code — otherwise things _will_ break.
>>
>> Since multiple packages put things in /lib/udev, I'm not sure it is
>> possible to establish a symlink from /lib/udev to /usr/lib/udev if
>> that's what you mean; I'll look into it though.
>
> Couldn't you, on udev upgrade, move everything in /lib/udev to
> /usr/lib/udev, and then make the symlink? Seems fairly simple
> to me, but maybe I'm overlooking something?
>
It seems like that would work well.
--
Thanks,
Zac
07-12-2012, 07:17 AM
Michał Górny
rfc: udev-rules.eclass
On Thu, 12 Jul 2012 13:01:21 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> wrote:
> > On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
> >> Il 11/07/2012 21:11, William Hubbs ha scritto:
> >> > I am about to release udev-186-r1, which will move everything
> >> > currently in /lib/udev to /usr/lib/udev.
> >>
> >> Unless you're going to establish a symlink, please keep it under
> >> p.mask until everything is using some common code — otherwise
> >> things _will_ break.
> >
> > Since multiple packages put things in /lib/udev, I'm not sure it is
> > possible to establish a symlink from /lib/udev to /usr/lib/udev if
> > that's what you mean; I'll look into it though.
>
> Couldn't you, on udev upgrade, move everything in /lib/udev to
> /usr/lib/udev, and then make the symlink? Seems fairly simple
> to me, but maybe I'm overlooking something?
You are overlooking conflicts introduced through moving files without
updating vardb.
--
Best regards,
Michał Górny
07-12-2012, 07:33 AM
Zac Medico
rfc: udev-rules.eclass
On 07/12/2012 12:17 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 13:01:21 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> wrote:
>>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
>>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>>>>> I am about to release udev-186-r1, which will move everything
>>>>> currently in /lib/udev to /usr/lib/udev.
>>>>
>>>> Unless you're going to establish a symlink, please keep it under
>>>> p.mask until everything is using some common code — otherwise
>>>> things _will_ break.
>>>
>>> Since multiple packages put things in /lib/udev, I'm not sure it is
>>> possible to establish a symlink from /lib/udev to /usr/lib/udev if
>>> that's what you mean; I'll look into it though.
>>
>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>> /usr/lib/udev, and then make the symlink? Seems fairly simple
>> to me, but maybe I'm overlooking something?
>
> You are overlooking conflicts introduced through moving files without
> updating vardb.
>
Maybe that's package manager dependent. I think it should work fine with
Portage though.
--
Thanks,
Zac
07-12-2012, 01:43 PM
Ian Stakenvicius
rfc: udev-rules.eclass
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/07/12 01:01 AM, Ben de Groot wrote:
> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> wrote:
>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò
>> wrote:
>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>>>> I am about to release udev-186-r1, which will move everything
>>>> currently in /lib/udev to /usr/lib/udev.
>>>
>>> Unless you're going to establish a symlink, please keep it
>>> under p.mask until everything is using some common code —
>>> otherwise things _will_ break.
>>
>> Since multiple packages put things in /lib/udev, I'm not sure it
>> is possible to establish a symlink from /lib/udev to
>> /usr/lib/udev if that's what you mean; I'll look into it though.
>
> Couldn't you, on udev upgrade, move everything in /lib/udev to
> /usr/lib/udev, and then make the symlink? Seems fairly simple to
> me, but maybe I'm overlooking something?
>
A symlink isn't a good idea as, iirc, the new udev still -reads- from
both /usr/lib/udev and /lib/udev .. so it'd have two sources for the
exact same rules; could be an issue.
Given this, the way I see it all we need is a helper s.t. all installs
going forward put the rules into the right place according to the
installed udev (or maybe the installed virtual/device-manager) so that
ebuilds/packages dont need to worry about setting the paths
explicitly; and eventually as things progress all the rules in
/lib/udev will get cleaned out in favour of /usr/lib/udev ... ?
We could always just forgo the helper and make all packages migrate
via a >=udev-186-r1 dep and setting the rules install paths explicitly
to /usr/lib/udev ... the helper (to me) just makes this cleaner in
the ebuild..
On 12/07/12 03:17 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot <yngwin@gentoo.org>
> wrote:
>
>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
>> wrote:
>>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò
>>> wrote:
>>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>>>>> I am about to release udev-186-r1, which will move
>>>>> everything currently in /lib/udev to /usr/lib/udev.
>>>>
>>>> Unless you're going to establish a symlink, please keep it
>>>> under p.mask until everything is using some common code —
>>>> otherwise things _will_ break.
>>>
>>> Since multiple packages put things in /lib/udev, I'm not sure
>>> it is possible to establish a symlink from /lib/udev to
>>> /usr/lib/udev if that's what you mean; I'll look into it
>>> though.
>>
>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>> /usr/lib/udev, and then make the symlink? Seems fairly simple to
>> me, but maybe I'm overlooking something?
>
> You are overlooking conflicts introduced through moving files
> without updating vardb.
>
There were no vdb issues when baselayout-1 was migrated to
baselayout-2, and it rewrote a whackload of stuff iirc...
Updating vdb shouldn't be an issue here, as long as pkg_postinst
doesn't crash mid-stream. Is the vdb common between package managers
or does each one have a different solution?
On Thu, 12 Jul 2012 09:47:33 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 12/07/12 03:17 AM, Michał Górny wrote:
> > On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot <yngwin@gentoo.org>
> > wrote:
> >
> >> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
> >> wrote:
> >>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò
> >>> wrote:
> >>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
> >>>>> I am about to release udev-186-r1, which will move
> >>>>> everything currently in /lib/udev to /usr/lib/udev.
> >>>>
> >>>> Unless you're going to establish a symlink, please keep it
> >>>> under p.mask until everything is using some common code —
> >>>> otherwise things _will_ break.
> >>>
> >>> Since multiple packages put things in /lib/udev, I'm not sure
> >>> it is possible to establish a symlink from /lib/udev to
> >>> /usr/lib/udev if that's what you mean; I'll look into it
> >>> though.
> >>
> >> Couldn't you, on udev upgrade, move everything in /lib/udev to
> >> /usr/lib/udev, and then make the symlink? Seems fairly simple to
> >> me, but maybe I'm overlooking something?
> >
> > You are overlooking conflicts introduced through moving files
> > without updating vardb.
> >
>
> There were no vdb issues when baselayout-1 was migrated to
> baselayout-2, and it rewrote a whackload of stuff iirc...
>
> Updating vdb shouldn't be an issue here, as long as pkg_postinst
> doesn't crash mid-stream. Is the vdb common between package managers
> or does each one have a different solution?
Yes, it is common because for many years people keep noticing it is
common and using that. In other words, for many there is a failing
attempt to stop relying on its format.
rfc: udev-rules.eclass
