| 1 |
On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle <tomka@g.o> wrote: |
| 2 |
> On 11/13/2013 12:39 PM, Tom Wijsman wrote: |
| 3 |
>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) |
| 4 |
>> Martin Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
| 5 |
>> |
| 6 |
>>> Hello. |
| 7 |
>>> |
| 8 |
>>> The new "features" use.stable.mask and package.use.stable.mask |
| 9 |
>>> have turned maintaining systems with mixed ARCH and ~ARCH keywords |
| 10 |
>>> into a nightmare: |
| 11 |
>> |
| 12 |
>> They are considered unsupported by many; so, going down that path you |
| 13 |
>> need to be acquainted with Portage enough to keep a consistent system. |
| 14 |
> |
| 15 |
> This argument has come up several times, but is it valid? |
| 16 |
|
| 17 |
Honestly, opinions vary on this one and I don't think it is a |
| 18 |
productive path to go down. I also feel that being able to mix |
| 19 |
keywords is a big benefit of using Gentoo. I'd rather focus on |
| 20 |
practical ways to make this easier rather than whether it is |
| 21 |
desirable. |
| 22 |
|
| 23 |
That said, there are always going to be situations where mixing |
| 24 |
keywords isn't practical. You're not going to run stable chromium |
| 25 |
against ~arch v8, or mixed keywords between kdelibs and kwin, etc. |
| 26 |
|
| 27 |
> We could consider reducing the feature set of portage and live |
| 28 |
> with the "problems" that arise. When I started using Gentoo a |
| 29 |
> package could simply not go stable until all dependencies for all |
| 30 |
> USE flags were also stable. Masking USE flags was reserved to a |
| 31 |
> short list of very special architecture depend special cases. |
| 32 |
|
| 33 |
I don't think going backwards is the solution. Back in the old days |
| 34 |
packages broke from time to time because we didn't have adequate ways |
| 35 |
to express dependencies, and I don't think it is a good solution to |
| 36 |
strip USE flags out of packages when they go stable so that users |
| 37 |
don't even have the option to use them. |
| 38 |
|
| 39 |
It makes more sense to identify what specifically is causing problems |
| 40 |
and come up with better solutions to them. That said, your original |
| 41 |
email contained a few separate issues and they're probably best dealt |
| 42 |
with individually. We're not going to have a common solution for |
| 43 |
multilib, stable use masking, python-exec, and whatever other issues |
| 44 |
are lurking beneath the surface. |
| 45 |
|
| 46 |
Rich |
Archives