1 |
> because a number of other packages want to see /usr/src/linux for the |
2 |
> running kernel. lm-sensors, vmware, nvidia, ... |
3 |
|
4 |
I was referring to the ordinary packages (not the kernels) when talking |
5 |
about moving the unpacked source from /var/tmp/portage/*/work to |
6 |
/usr/src. As it's almost always necessary for user-interaction when |
7 |
configuring the kernel it's needed for the source of the kernel to |
8 |
remain in /usr/src and not be removed as soon as emerge is finished |
9 |
doing it's thing. But the ordinary packages' source-code can be safely |
10 |
removed after the merge (if you don't want to do something special to |
11 |
the source in case you would use the ebuild-command instead). I thought |
12 |
it was pretty clear what I meant in my previous post... |
13 |
|
14 |
> I do agree that some effort should be put into fixing the unwanted |
15 |
> effects that occur when you install another kernel though (haveing to |
16 |
> reinstall all kernel related packages, and unable to keep already |
17 |
> installed versions) - I am sure someone must have had a bug against |
18 |
> that one. |
19 |
|
20 |
I'm sure alot of people do =) As am I. |
21 |
|
22 |
> On Sun, 2003-10-05 at 02:27, Patrick Börjesson wrote: |
23 |
> > > In theory, Portage could track them if ebuild could be modified to |
24 |
> > > use/usr/src/pkg when it existed instead of /var/tmp/portage/*/work |
25 |
> > > and the application was installed via 'ebuild pkg merge'. I'm not |
26 |
> > > sure how possible that would be for implementation, though. |
27 |
> > |
28 |
> > But then the question is: Why? We already have the source unpacked |
29 |
> > in/var/tmp/portage/*/work so why "move" it to /usr/src? There are |
30 |
> > already ways for people to do the configure- and make-steps them |
31 |
> > selves if they |
32 |
|
33 |
Patrick Börjesson |
34 |
|
35 |
-- |
36 |
Public key id: 4C5AB0BF |
37 |
Public key available at search.keyserver.net[:11371] |