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, 07:58 PM
Samuli Suominen
 
Default rfc: udev-rules.eclass

On 07/11/2012 10:11 PM, William Hubbs wrote:

All,
I am about to release udev-186-r1, which will move everything currently
in /lib/udev to /usr/lib/udev.

For packages that install udev rules in ${FILESDIR}, we need an eclass
that tests the version of udev installed on the user's system and
installs the udev rules in the proper place. I'm not sure how many
packages do this, so if it is a very small number of packages, it may
not be worth the eclass. It would be good to discuss that as well as
reviewing the proposed eclass.

Thanks,

William



Please don't hardcode the path like this, use pkg-config instead:

inherit toolchain-funcs

dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
 
Old 07-12-2012, 08:31 PM
Mike Gilbert
 
Default rfc: udev-rules.eclass

On Thu, Jul 12, 2012 at 3:58 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Please don't hardcode the path like this, use pkg-config instead:
>
> inherit toolchain-funcs
>
> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>

Heh, I didn't realize udev installed a pkg-config file for that. Nice.
 
Old 07-12-2012, 09:01 PM
Samuli Suominen
 
Default rfc: udev-rules.eclass

On 07/13/2012 12:04 AM, Michał Górny wrote:

On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:


On 07/11/2012 10:11 PM, William Hubbs wrote:

All,
I am about to release udev-186-r1, which will move everything
currently in /lib/udev to /usr/lib/udev.

For packages that install udev rules in ${FILESDIR}, we need an
eclass that tests the version of udev installed on the user's
system and installs the udev rules in the proper place. I'm not
sure how many packages do this, so if it is a very small number of
packages, it may not be worth the eclass. It would be good to
discuss that as well as reviewing the proposed eclass.

Thanks,

William



Please don't hardcode the path like this, use pkg-config instead:

inherit toolchain-funcs

dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"


Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...



Obviously the pkg-config should be only the primary method and there
should be a fallback, like what has already been posted.


See attachment.
 
Old 07-12-2012, 09:04 PM
Michał Górny
 
Default rfc: udev-rules.eclass

On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 07/11/2012 10:11 PM, William Hubbs wrote:
> > All,
> > I am about to release udev-186-r1, which will move everything
> > currently in /lib/udev to /usr/lib/udev.
> >
> > For packages that install udev rules in ${FILESDIR}, we need an
> > eclass that tests the version of udev installed on the user's
> > system and installs the udev rules in the proper place. I'm not
> > sure how many packages do this, so if it is a very small number of
> > packages, it may not be worth the eclass. It would be good to
> > discuss that as well as reviewing the proposed eclass.
> >
> > Thanks,
> >
> > William
> >
>
> Please don't hardcode the path like this, use pkg-config instead:
>
> inherit toolchain-funcs
>
> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"

Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...

--
Best regards,
Michał Górny
 
Old 07-12-2012, 09:09 PM
Samuli Suominen
 
Default rfc: udev-rules.eclass

On 07/13/2012 12:01 AM, Samuli Suominen wrote:

On 07/13/2012 12:04 AM, Michał Górny wrote:

On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:


On 07/11/2012 10:11 PM, William Hubbs wrote:

All,
I am about to release udev-186-r1, which will move everything
currently in /lib/udev to /usr/lib/udev.

For packages that install udev rules in ${FILESDIR}, we need an
eclass that tests the version of udev installed on the user's
system and installs the udev rules in the proper place. I'm not
sure how many packages do this, so if it is a very small number of
packages, it may not be worth the eclass. It would be good to
discuss that as well as reviewing the proposed eclass.

Thanks,

William



Please don't hardcode the path like this, use pkg-config instead:

inherit toolchain-funcs

dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"


Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...



Obviously the pkg-config should be only the primary method and there
should be a fallback, like what has already been posted.

See attachment.


Err, this one.
 
Old 07-12-2012, 09:39 PM
Jonathan Callen
 
Default rfc: udev-rules.eclass

On 07/12/2012 05:09 PM, Samuli Suominen wrote:
> @@ -33,10 +35,14 @@
> # Get unprefixed udev rules directory.
> _udev_get_rulesdir() {
> local dir
> - if has_version '<sys-fs/udev-186-r1'; then
> - dir=/lib/udev/rules.d
> + if "$($(tc-getPKG_CONFIG) --exists udev)"; then

This should probably be:

if $(tc-getPKG_CONFIG) --exists udev 2>/dev/null; then

> + dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
> else
> - dir=/usr/lib/udev/rules.d
> + if has_version '<sys-fs/udev-186-r1'; then
> + dir=/lib/udev/rules.d
> + else
> + dir=/usr/lib/udev/rules.d
> + fi
> fi
> echo -n $dir
> }

--
Jonathan Callen
 
Old 07-13-2012, 05:44 AM
Brian Dolbec
 
Default rfc: udev-rules.eclass

On Thu, 2012-07-12 at 12:30 -0400, Alexis Ballier wrote:
> On Wed, 11 Jul 2012 20:41:04 -0700
> Brian Dolbec <dolsen@gentoo.org> wrote:
>
> > 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.
> [...]
>
> how do you handle the package manager database containing the location
> of the file ?
>
> A.
>

Personally, since I'm not a bash programmer, I'd use python. And since
this is the package managers db, I'd use the pkg manager to do it.
Specifically I'd create an emaint module to do it in the fully
modular/plug-in-able emaint rewrite I did (waiting for Zac's review,
merge). It can make it's modules fully available for direct or managed
import by other portage code, or other scripts. In fact in that branch I
moved some clean-logs code from emerge into an emaint module, extended
it a bit so you can change the time setting, run pretend runs (-c,
--check)... and had the emerge FEATURE run it instead. So you could run
it independently of emerge if you choose.

There is an outdated vdbkeys emaint module that did changes and updates
to several files in a pkg's vdb directory. Creating one to do this
should be quite simple.

That said, I don't profess to know what other possible ramifications
there would be to changing a few entries in a pkg's CONTENTS file. I'll
leave that up to Zac and the others. But I haven't heard any screaming
of breakage that would occur for doing so.
--
Brian Dolbec <dolsen@gentoo.org>
 
Old 07-13-2012, 06:29 AM
Duncan
 
Default rfc: udev-rules.eclass

Zac Medico posted on Thu, 12 Jul 2012 00:33:50 -0700 as excerpted:

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

Confirmed. This is the way amd64 has handled the lib -> lib64 symlink
(sometimes reversed) for years (which is why the whole FEATURES=multilib-
strict thing was needed to try and keep things straight). As long as the
symlink is there, portage will follow the symlink and manage the files
just fine.

FWIW, a similar trick was used when migrating X-related stuff from
/usr/X11R6/ to simply /usr/ . The files were moved up a level into /usr,
and /usr/X11R6 became a symlink -> . , thus pointing back to /usr/ .
IIRC, existing package versions still continued to own their /usr/X11R6/
*, the DB wasn't changed. New versions simply moved directly into /usr/,
and the problem gradually solved itself until it was down to a manageable
size for a final push to get the old location out of the tree. (I just
checked and it appears nothing owns that symlink on my system, now...
unless I screwed up my equery|grep... )

Now if the symlink somehow gets lost before all packages have moved their
paths...

But that trick has been used enough in gentoo, especially in gentoo/
amd64, that every PM should cope with it just fine, or said PM would be
rather broken.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 07-13-2012, 06:12 PM
William Hubbs
 
Default rfc: udev-rules.eclass

All,

mgorny has written a patch for udev, which if it gets accepted, will
make it read rules from /lib/udev/rules.d, so there will be nothing that
we need to do on our side at all.

William
 

Thread Tools




All times are GMT. The time now is 04:47 PM.

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