| 1 |
On Friday 23 June 2006 14:35, Jure Varlec wrote: |
| 2 |
> I apologize if this was previously discussed, but I couldn't find anything |
| 3 |
> on gmane. And maybe I should post this on gentoo-devel, but I'm not going |
| 4 |
> to molest developers until I understand portage better. Knowing there are |
| 5 |
> users here with good knowledge of portage I thought I would ask here first. |
| 6 |
|
| 7 |
Good call. :) |
| 8 |
|
| 9 |
[SNIP] |
| 10 |
> When I asked it to show me which |
| 11 |
> packages depended on a certain gnome lib, it dutifully presented me with the |
| 12 |
> answer. The trick is, those packages were compiled with USE="-gnome". And |
| 13 |
> looking at their ebuilds, dependency handling was correct and they did not |
| 14 |
> depend on those libs. |
| 15 |
|
| 16 |
How did you determine that? Did the ebuild inherit any eclasses and did you |
| 17 |
look in those? Also make sure you have >=gentoolkit-0.2.2. |
| 18 |
|
| 19 |
> So portage never built this packages with gnome support. So why did they |
| 20 |
> depend on gnome libs? I now believe that the libs were installed prior to |
| 21 |
> the package in question, and the package's configure script detected that |
| 22 |
> and compiled the package against the lib. This may be wrong; in that case, |
| 23 |
> someone please explain what's going on. But if it's true, it raises two |
| 24 |
> more questions. |
| 25 |
|
| 26 |
Remember USE flags are for *optional* dependencies. Mandatory dependencies |
| 27 |
will remain no matter what USE flags you set. |
| 28 |
|
| 29 |
[SNIP] |
| 30 |
> But I'd like to know: how, in principle, |
| 31 |
> does equery (and, supposedly, portage) know that a certain package depends |
| 32 |
> on a lib, when the decision to depend on it was made by the configure |
| 33 |
> script independent of what portage was told to do via USE flags or hard |
| 34 |
> dependencies? |
| 35 |
|
| 36 |
The decision should not be made independent of what portage was told. If it is |
| 37 |
that would be a bug in the ebuild. |
| 38 |
|
| 39 |
> And secondly: why the heck does portage allow configure autodetection? Why |
| 40 |
> don't ebuilds specify explicitly, depending on USE flags, what to build and |
| 41 |
> what not to build? |
| 42 |
|
| 43 |
It does specify dependencies explicitly in the ebuilds depending on USE flags. |
| 44 |
If it does not it is a bug. |
| 45 |
|
| 46 |
> And to finish the story, I played around with equery long enough to find |
| 47 |
> everything I deemed to be part of gnome, removed it, and rebuilt everything |
| 48 |
> that was unjustly depending on it. Without changing the USE flags, of |
| 49 |
> course -- they've never been set anyway. Emerge never pulled anything back |
| 50 |
> in, and now everything works beautifully, telling me I am right at least in |
| 51 |
> some respects. But I'd like to have the situation cleared up, so I'm |
| 52 |
> turning to you. |
| 53 |
|
| 54 |
Portage cannot prevent an autoconfigure script from detecting stuff that the |
| 55 |
ebuild does not depend on. But as stated above it would be regarded as a bug |
| 56 |
when it does. The devs have two options to fix such a bug. Either patch the |
| 57 |
configure script to disable detection of additional stuff (when USE flag is |
| 58 |
disabled) or add the detected stuff as mandatory dependencies. |
| 59 |
|
| 60 |
This also explains why applications that depend on gnome-python-extras like |
| 61 |
e.g. meld have ridiculous dependencies like totem and nautilus-burner. To get |
| 62 |
rid of those dependencies someone must patch the configure script of |
| 63 |
gnome-python-extras to allow USE flags to disable them with switches. |
| 64 |
|
| 65 |
HtH |
| 66 |
|
| 67 |
-- |
| 68 |
Bo Andresen |
Archives