From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: About udev-145: new features / extras and kernel requirements
Date: Sun, 30 Aug 2009 15:26:36 +0000 (UTC) [thread overview]
Message-ID: <pan.2009.08.30.15.26.35@cox.net> (raw)
In-Reply-To: 6f8b45100908300724h206273b0i9f36cbdf8ef9d271@mail.gmail.com
Arun Raghavan posted on Sun, 30 Aug 2009 19:54:47 +0530 as excerpted:
> 2009/8/30 Matthias Schwarzott <zzam@gentoo.org>:
>> Hi there!
>>
>> The new udev-145 and newer have some new kernel requirements. How
>> should the ebuild verify they are met?
>> Some possible ways:
>> 1. Check config under /usr/src/linux
>> 2. Check /proc/config.gz
>> 3. Print message for user in pkg_postinst
>
> All of the above? Rationale being (1) is required to check against the
> kernel you're supposedly using, (2) for the kernel you definitely are
> using, and (3) to make sure people remember.
Indeed, all of the above, but not requiring the first two only giving
their status in #3.
Some people don't have the kernel option enabling /proc/config.gz turned
on, so #2 isn't reliable, and #1, /usr/src/linux, could point who /knows/
where, maybe something current, maybe not. (Here, it points at my local
kernel git repo... which may or may not correspond to the currently
running kernel, tho it's usually reasonably close, and it's usually
within a few days of upstream unless I'm git bisecting some bug.)
Thus, neither of the first two is reliable, but checking them and putting
the status in #3 should be helpful.
Another alternative, ultimately safer: add another option, and require
that at least one of the three pass:
1-2 as they are.
3. Check UDEV_ASSUME_KERNEL_OPTS in the environment (could be set in
make.conf for portage and compatible PMs).
Then in the message corresponding to the original #3 except presumably in
unpack or prepare, report status as a reminder, and die if none of the
above tests pass. #3, the env var, would allow users to override without
hacking the ebuild itself, if for some reason they decided they needed
to. If it's the only one that passes, ewarn/eerror to the effect
"Relying on UDEV_ASSUME_KERNEL_OPTS override. If it breaks, you get to
keep the pieces!"
--
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
next prev parent reply other threads:[~2009-08-30 10:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 14:11 [gentoo-dev] About udev-145: new features / extras and kernel requirements Matthias Schwarzott
2009-08-30 14:24 ` Arun Raghavan
2009-08-30 15:26 ` Duncan [this message]
2009-08-30 14:46 ` Nirbheek Chauhan
2009-08-30 15:45 ` William Hubbs
2009-08-30 16:18 ` Mike Auty
2009-08-31 15:46 ` Jeremy Olexa
2009-08-31 4:25 ` Lars Wendler
2009-08-30 15:05 ` Bruno
2009-08-30 19:20 ` Robin H. Johnson
2009-11-09 16:35 ` Mart Raudsepp
2009-11-12 9:08 ` Matthias Schwarzott
2009-11-09 19:22 ` Daniel Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2009.08.30.15.26.35@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox