FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-12-2012, 02:50 AM
Zac Medico
 
Default rfc: udev-rules.eclass

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
 
Old 07-12-2012, 03:03 AM
"Rick "Zero_Chaos" Farina"
 
Default 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/

iQIcBAEBAgAGBQJP/j6aAAoJEKXdFCfdEflKyJMQAJZIm4YNbmYl7EjFCU4JaNjg
PJAwz1kSCCmhiQYw60FHEvdZdC4cR5v/VhBpHW0Im53yTRE6vgwjrFybze0YG9u7
UYNbz6jAZ5HYSj5CCxxCwSMricREBJcnRqZU8til8M3ayw4jI7 IpRQJYOdjd923T
M2b7YFW64JrGXZtpUR2Uc9KMDdgAVoMmIp5JmERTYiJxqu8Rhd AWBD8Ey8xsQQIX
+mT+rkoIRc5VSEnsJues59TecSDdEgYYdYGwDv81euMBTYbEbu NolImav8L2AxJZ
8k4jXPF8oVn73ehmLKjenkeiYJHVBiPycG53Q95f7Hs/YavXChtcrOg6MLsdhfTn
tqrClTvOu3rvaboIfGF+QXWpi+kH0ltlPLNIyH0Q0bPCnHmwAt b43NqqprFo77/v
pMkjOzRZ5rf6p+SnCE6ouwZMJS4FYSWsGKIoRwBgQm6eCj9RXN V59lFe0zW2pi9b
Qf/AwR16ZeNWQovHCxYmUupGwLtEbB12sDP9hSnq+FcHAMbwvcyZa mxibo9DPY+K
eNc9kn7cvHu+Z3B1O3O1yfIKwYsTeVkZUMw1Sn1Y3SwtwXBNnW c/8YM41pdjSfpK
bydnt8FTUeLUhLtIYzUtsN9s99S3u2rhfkPUWapeNdYYCOCMrx Ml3tx52rNFggwT
w03B9r0mUngc5DBzaUg6
=sg7B
-----END PGP SIGNATURE-----
 
Old 07-12-2012, 03:41 AM
Brian Dolbec
 
Default rfc: udev-rules.eclass

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>
 
Old 07-12-2012, 05:01 AM
Ben de Groot
 
Default 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
 
Old 07-12-2012, 05:26 AM
Zac Medico
 
Default 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
 
Old 07-12-2012, 07:17 AM
Michał Górny
 
Default 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
 
Old 07-12-2012, 07:33 AM
Zac Medico
 
Default 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
 
Old 07-12-2012, 01:43 PM
Ian Stakenvicius
 
Default 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..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1J0ACgkQ2ugaI38ACPAaRgEAuknxIx3LOgVniVsEqxrwWfnj
vNW5Zc/6/ZCn8QL+LZ8A/iepdgiZ7bmYtUb+Zj537o46z/prXP290q6oo/2DQy2j
=G32M
-----END PGP SIGNATURE-----
 
Old 07-12-2012, 01:47 PM
Ian Stakenvicius
 
Default rfc: udev-rules.eclass

-----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?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1XUACgkQ2ugaI38ACPBKdgD/S3jlct63PVIKE8UmHW4jEanZ
T2/lgnF/cUzTSlsyrEQA/iQWSvOcowsgI/r2VUlJLFpltNVea/f8pm5wKq5F4cjk
=HA5O
-----END PGP SIGNATURE-----
 
Old 07-12-2012, 02:19 PM
Michał Górny
 
Default rfc: udev-rules.eclass

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.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 01:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org