1 |
On Wednesday 22 October 2003 3:40, Spider wrote: |
2 |
|
3 |
> Because, they are two of the problematic builds that are affected by |
4 |
> your suggested way of fixing, or breaking, things. This was not |
5 |
> personally directed at you, but taken out as examples of packages that |
6 |
> can't just depend on "What am I running right now" Because of how they |
7 |
> work. |
8 |
|
9 |
Point taken. But even if I had this magical fix for the situation, I don't |
10 |
have need for those packages and my solution would be handicapped thusly. |
11 |
|
12 |
> Curently my counterproposal is to actually have the usr/src/linux |
13 |
> symlink directed at the target kernel, and if that link isn't found, |
14 |
> assume that we want the running kernel instead, and repoint it at |
15 |
> lib/modules/`uname -r`/build |
16 |
> |
17 |
> Just because usr/src/linux is a symlink in our case, why is that worse |
18 |
> than following and relying on the /lib/modules/`uname -r`/build |
19 |
> symlink? The name? if that's the case, we could well make the |
20 |
> symlink named "Target" and instead just confuse people more. |
21 |
|
22 |
Okay, but your counterproposal would be flawed as well, because as you pointed |
23 |
out, you don't always keep your sources, and without those /usr/src/linux |
24 |
will point to nothing, as well as the /lib/modules/`uname -r`/build link. So |
25 |
what happens when those both fail? Do we fake a dir in /usr/src, so at leats |
26 |
one link works? |
27 |
|
28 |
> Yes, I'm of the old school , I -assume- that people who suggest a way |
29 |
> of doing things, also have tried it themselves, or are capable of |
30 |
> implementing it. When you don't have that situation, you get "Designed |
31 |
> by Commite" solutions that may sound good, but are in fact unworkable. |
32 |
|
33 |
But in order to try this myself (if I was capable), I would need to atleast |
34 |
account for quite a few pieces of equipment that I don't currently own in |
35 |
order to support all posible scenarios, of which I couldn't afford to do, nor |
36 |
find storage for. In order to cover the most possible cases, we need "Design |
37 |
by Committe" with the people using this equipment. |
38 |
|
39 |
> The personal form "i" which I used througout the whole email suggests |
40 |
> that in this case it is my personal opinion. To assume that it is that |
41 |
> of a team, whom I've been sent forth to represent, is plain silly. |
42 |
|
43 |
Regardless of this being your personal opinion, you're still a dev, and when |
44 |
devs say "worksforme" it tends to be the end of development and/or |
45 |
discussion, personal opinion or not. I don't assume the rest of the dev team |
46 |
agrees with you or otherwise. In fact, I'm gonna say most of them probably |
47 |
have given little thought to it one way or the other. |
48 |
|
49 |
|
50 |
> And, in my not overly humble opinion, You have just as much to say as |
51 |
> anyone else. Its not about your email address. |
52 |
|
53 |
I've found that I usually have more to say than anyone else, its the getting |
54 |
people to relate part I have trouble with:) |
55 |
-- |
56 |
Chuck Brewer |
57 |
Registered Linux User #284015 |
58 |
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred. |