1 |
On Thu, 2004-02-05 at 03:55, Spider wrote: |
2 |
> begin quote |
3 |
> On Thu, 05 Feb 2004 03:16:15 +0100 |
4 |
> John Nilsson <john@×××××××.nu> wrote: |
5 |
> |
6 |
> > If they are linked agains 0.9.7 should they not rdepend on 0.9.7 ? |
7 |
> > |
8 |
> > I admit I have no clue as how GRP works. But this is what I gather: by |
9 |
> > using the -k you tell portage to just unpack allready compiled |
10 |
> > packages for the ebuild it's trying to install. |
11 |
> |
12 |
> the GRP works just as normal packages do, the metadata is exactly the |
13 |
> same as in an installed system. Thats where the problem lies in a case |
14 |
> like this. |
15 |
|
16 |
Yeah, that was what I was thinking. |
17 |
|
18 |
> |
19 |
> |
20 |
> > Why not just have a package-grp-x.x.x.ebuild that has a binary package |
21 |
> > as source, and just skips the compile step? This ebuild should have |
22 |
> > the correct RDEPEND... |
23 |
> > |
24 |
> |
25 |
> Erm? that sort of doesn't make sense.. a grp contains the ebuild + the |
26 |
> files that would be merged into the system, thereby skipping the |
27 |
> "download unpack compile install" parts, but performing the other parts |
28 |
> from the ebuild, maintaining the RDEPEND only. |
29 |
|
30 |
Poit beeing that a seperate ebuild would allow RDEPEND to be set to the |
31 |
actual package it was compiled against (=package-x.x.x) without messing |
32 |
with the more general case ebiulds and killing the requirement to |
33 |
engineer a special case handling in portage. |
34 |
|
35 |
> |
36 |
> btw, why wasn't this reply sent to the list? |
37 |
Sorry, missed the "reply all"-button. |
38 |
|
39 |
> //Spider |
40 |
> |
41 |
> |
42 |
|
43 |
-John |