1 |
On Sat, Feb 2, 2013 at 2:17 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
2 |
> On Sat, 2 Feb 2013 16:21:10 +0100 |
3 |
> Alex Schuster <wonko@×××××××××.org> wrote: |
4 |
> |
5 |
>> Michael Mol writes: |
6 |
>> |
7 |
>> > So, I botched the upgrade to udev-191. I thought I'd followed the |
8 |
>> > steps, but I apparently only covered them for one machine, not both. |
9 |
>> |
10 |
>> [...] |
11 |
>> |
12 |
>> > Udev also complained about DEVTMPFS not being enabled in the |
13 |
>> > kernel.[2] I couldn't get into X, but I could log in via getty and |
14 |
>> > a plain old vt, so I enabled it, rebuilt the kernel, installed it |
15 |
>> > and rebooted...and now that's presumably covered. |
16 |
>> |
17 |
>> Ran into the same problem, with my sister's PC. Which I had updated |
18 |
>> from remote, so I did not see the elogs. I do not think it is correct |
19 |
>> behaviour to continue building udev although the system wouldn't boot |
20 |
>> with that kernel option missing. I would expect the udev ebuild to |
21 |
>> check the running kernel for that option, and refuse to build until |
22 |
>> it has it set. Or until building is forced by some USE flag or an |
23 |
>> environment variable. |
24 |
>> |
25 |
>> Had these things not been handled better in the past? |
26 |
> |
27 |
> There's a furious debate going on in -dev about this very thing, and |
28 |
> the bottom line is that your statements above are way too simplistic. |
29 |
> |
30 |
> - there is no guarantee that /proc/config.gz represents the kernel the |
31 |
> binary will actually run on (this emerge might well be the last |
32 |
> process you ever run on that kernel) |
33 |
> - there is no guarantee that /usr/src/linux corresponds to anything at |
34 |
> all (it's a symlink and can point to anything, even invalid stuff) |
35 |
> - there is no guarantee that the build host will run the code (think |
36 |
> build farms, crossdev etc, so every available config cannot possibly |
37 |
> be valid) |
38 |
> - and a couple more |
39 |
> |
40 |
> Basically, the only thing left for the ebuild devs is to notify the |
41 |
> user with the important information. |
42 |
> |
43 |
> The question is not whether to halt the build or not (that cannot and |
44 |
> will not be done) but how to do the communication: |
45 |
> |
46 |
> - news item |
47 |
> - elog |
48 |
> - README |
49 |
> - some arb notice on a web site somewhere |
50 |
> ..... |
51 |
> |
52 |
> This is gentoo, the distro that does not hold your hand and gives you |
53 |
> every opportunity to keep both pieces. This is a good example of such. |
54 |
|
55 |
I'm no longer subscribed to -dev, so I must have missed that |
56 |
thread.[1] My *preference* in these matters is twofold: |
57 |
|
58 |
1) Don't depend on the running kernel. I'd like to be able to use |
59 |
portage to cross-compile from one amd64 box to another[2], and the |
60 |
running kernel will be different from the kernel I'm compiling for. |
61 |
2) Just as we have autounmask-write to force us through a manual |
62 |
confirmation step if we have to change USE flags or unmask something, |
63 |
I'd like autounmask to be able to service an "are you sure you want to |
64 |
override this particular serious warning?" behavior. It'd actually be |
65 |
pretty simple to do with per-package USE flags, and, since autounmask |
66 |
only operates on exact versions of packages, you'd be asked for |
67 |
confirmation on every upgrade. Yes, autounmask makes a mess of |
68 |
/etc/portage/package.use over time, but that's why you should |
69 |
periodically go through and sweep the cobwebs out of there. |
70 |
|
71 |
[1] What with unexpectedly losing my job, I suddenly had even less |
72 |
time than I already had, since I needed to dive full-bore into job |
73 |
hunting. |
74 |
[2] Different CFLAGS, distcc isn't a good option in my circumstance, |
75 |
and I'd risk an "illegal instruction" error a binary in a chroot used |
76 |
an instruction available on the target machine's CPU, but not on the |
77 |
source machine's CPU. |
78 |
|
79 |
-- |
80 |
:wq |