| 1 |
Diego Elio Pettenò wrote: |
| 2 |
> > Ah, I always thought of overlays as places where apps tend to reside, |
| 3 |
> > but of course you could have glibc in there for all we know... Good |
| 4 |
> > point... |
| 5 |
> |
| 6 |
> Welcome to the life of your average Gentoo ebuild maintainer. |
| 7 |
|
| 8 |
Stop complaining (and with foul language! come on, you sound like |
| 9 |
an idiot, which seems unneccessary) and let's think about solutions. |
| 10 |
|
| 11 |
Do I understand correctly that you consider the problem to be that |
| 12 |
it's not clear whether a system in a bug report has ebuilds from an |
| 13 |
overlay in the dependency chain or not? |
| 14 |
|
| 15 |
A very low resolution solution would be a tainted flag like the one |
| 16 |
in the kernel, but perhaps we can do something a bit better. |
| 17 |
|
| 18 |
emerge could output this information sometime before src_unpack. It |
| 19 |
would be very visible in every emerge log, and it would certainly be |
| 20 |
helpful for everyone who understands overlays - it's certainly easy |
| 21 |
to imagine that it could completely preempt some invalid bug reports. |
| 22 |
|
| 23 |
If I do an emerge I typically know if I want dependencies out of an |
| 24 |
overlay or not. |
| 25 |
|
| 26 |
Another potentially interesting vector is to add overlay policies to |
| 27 |
ebuilds, although this means introducing arbitrary limitations, which |
| 28 |
generally doesn't make sense. |
| 29 |
|
| 30 |
|
| 31 |
I'm sure there are more and better interesting solutions to this |
| 32 |
problem. Let's hear? |
| 33 |
|
| 34 |
|
| 35 |
//Peter |
Archives