| 1 |
On 28/02/14 16:59, hasufell wrote: |
| 2 |
> Samuli Suominen: |
| 3 |
> > It would be very helpful if INSTALL_MASK could be overriden from |
| 4 |
> > an ebuild, if user hasn't set otherwise. So it could be configured |
| 5 |
> > like USE_ORDER which is |
| 6 |
> > "env:pkg:conf:defaults:pkginternal:repo:env.d" So |
| 7 |
> > INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}" This |
| 8 |
> > would be very helpful in preventing people from shooting themself |
| 9 |
> > in the foot |
| 10 |
> |
| 11 |
> > The only problem is that I propably don't have enough python skills |
| 12 |
> > to make that happen w/ sys-apps/portage. But does the suggestion |
| 13 |
> > make sense? Should I open a feature request bug? |
| 14 |
> |
| 15 |
> |
| 16 |
> Introducing something like INSTALL_MASK_ORDER gives the user |
| 17 |
> effectively more ways to shoot himself in the foot, especially when |
| 18 |
> ebuilds start to rely on INSTALL_MASK in non-trivial ways (and I am |
| 19 |
> sure people will come up with stuff). |
| 20 |
> |
| 21 |
> Besides that, it is a very intrusive change of behavior. |
| 22 |
> |
| 23 |
> Anyway... I don't care about people who break their systems in such |
| 24 |
> stupid ways. It's not more dangerous than one of the other thousand |
| 25 |
> things you can do to break gentoo, such as "--nodeps". |
| 26 |
> |
| 27 |
> They gotta handle it. |
| 28 |
|
| 29 |
I'm okay with that. That's how I see it too. I was merely trying to |
| 30 |
propose a solution |
| 31 |
for some users (and even few developers). |
| 32 |
|
| 33 |
At least I have this thread now I can refer them to in gmane, to show it |
| 34 |
was discussed |
| 35 |
and the general consensus is what it is and that they have to take |
| 36 |
responsibility for |
| 37 |
their INSTALL_MASK, not me, or any other ebuild maintainer. |
Archives