1 |
On 24 Jul 2003 09:24:17 -0600 |
2 |
Dave Nellans <dnellans@×××××××.edu> wrote: |
3 |
|
4 |
> you explicitly inject some version but as long as you never add it to |
5 |
> your world file it won't be updated unless required by something that |
6 |
> depends on it. And in that case you are going to want to update |
7 |
> anyways, and you can just inject it again and build your own source |
8 |
> that satisfies the new dependancies. |
9 |
|
10 |
If pkgA depends on virtual/foo, and virtual/foo is instanciated by pkgB, |
11 |
then an "emerge -u pkgA" will try to update pkgB, whether it has been |
12 |
really emerged or injected. Hence, if pkgA is a world package, an |
13 |
"emerge -u world" can build an update of your injected package, and in |
14 |
the linux-source example, that's not what we want. |
15 |
|
16 |
Another issue is that the inject of pkgB to instanciate virtual/foo will |
17 |
only does what we expect if pkgB is the default package associated to |
18 |
virtual/foo in your profile "virtuals" dictionnary. This is because |
19 |
ebuilds are not parsed by inject (hence PROVIDE is ignored, and nothing |
20 |
gets added to your edb/virtuals). For instance, because gentoo-sources |
21 |
is the default value for virtual/linux-sources, if you inject |
22 |
vanilla-sources and then emerge something depending on |
23 |
virtual/linux-sources, gentoo-sources will be emerged. |
24 |
|
25 |
That's why I was suggesting the possibility to inject virtual packages, |
26 |
I think it would really be more clear when what the user wants is to |
27 |
satisfy the dependencies on this virtual packages. |
28 |
|
29 |
But dummy ebuilds are also an acceptable (and easier) way to do it. We |
30 |
can imagine a dummy category for such stub ebuilds, one for each virtual |
31 |
packages, so that "emerge dummy/linux-sources" would definitly |
32 |
instanciate virtual/linux-sources, because there would be no updates in |
33 |
this category. |
34 |
|
35 |
-- |
36 |
TGL. |
37 |
|
38 |
-- |
39 |
gentoo-dev@g.o mailing list |