Udev fb[0-9]* permissions

Bryan Kadzban bryan at kadzban.is-a-geek.net
Mon Oct 9 16:03:55 PDT 2006

Mark Rosenstand wrote:
> Iwouldn't it make sense to take the 50-udev-default.rules from the 
> suse directory (since they're well maintained) and the rest from the 
> udev directory, and patch as needed, instead of "forking" all the 
> files?

I am not aware of any way to patch "in-flight" -- if we used seds to do
the updates, we could just sed the various files as part of the copy
process.  But AFAIK patch only works in-place; we'd have to copy the
files and patch them afterward.  Or patch them first, then install them.
Either way, though, I suppose that's not a huge issue.  Actually, maybe
patch's -o option would be helpful.

But I don't see this bug as an argument for using the SuSE rules (or
modified SuSE rules, for that matter).  It was added years and years
ago, way back before *any* rules were included in the udev tarball.  It
was copied (more or less) from the MAKEDEV script.

Yes, using "standard" rules makes it less likely to introduce gratuitous
bugs, that's true.  But I'm not sure that the extra work of reevaluating
each upstream release that we put into the book is worth it, either.
For instance, if we did this now, we would have several patch hunks that
serve no purpose except fixing bugs (or inconsistencies) in the current
sample rules.  But the next release of udev will include these changes
as well.  If we basically have to look at the whole patchset at each
release to see which of our changes (if any) are already there, I think
that's a lot of work.

Today we can upgrade udev and udev-config independently (most of the
time anyway).  If we move to patches, we'll be tying the two together
more closely.

Now maybe it's no more work to merge our patchset "forward" into the
upstream rules than merging the upstream changes "backward" into our
rules.  But I suspect it would be more work.  It depends on the relative
frequency of upstream changes that duplicate our patch(es), I suppose.

> In any case, calling the default rules "25-lfs.rules" is probably not
> too good, since it contradicts with both the udev documentation and
> other distros.

Other distros I can see; most call it *-default.rules or something
similar.  Which would be fine, don't get me wrong.  But what does it
contradict in the udev docs?  I don't see anything in the udev(7)
manpage that mentions specific names for rules files.  Or isn't that
what you meant?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20061009/4bafef6d/attachment.sig>

More information about the lfs-dev mailing list