| 1 |
On Tue, 07 May 2019 23:47:30 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> While the large number of flags is practically invisible to user with |
| 5 |
> all the USE_EXPAND hiding, it negatively impacts pkgcheck. When |
| 6 |
> the number reached 10, CI became unusable. We're currently back down |
| 7 |
> to 8, thanks to powerpc team, but the problem is going to happen again |
| 8 |
> sooner or later. Ideally we'd improve pkgcheck but I'm not aware of |
| 9 |
> anyone having a good idea how to do it. |
| 10 |
|
| 11 |
|
| 12 |
While I don't disagree with your rationale below, I think this |
| 13 |
motivation is the wrong one: What sort of algorithm does it use |
| 14 |
to explode when going from 8 to 10 flags ?!? |
| 15 |
|
| 16 |
There's multilib that adds a lot of flags with a single eclass change, |
| 17 |
but I'd guess the number of packages and flags is constantly growing, |
| 18 |
so sooner or later you'll be hit by this again and no multilib killing |
| 19 |
will help you then. |
| 20 |
|
| 21 |
I think it is more future proof to use the addition of multilib flags |
| 22 |
to fix pkgcheck rather than actively reducing the number of multilib |
| 23 |
flags to cope with its limitations. |
| 24 |
|
| 25 |
Also, remember that multilib is not entirely about skype or slack, |
| 26 |
this was made with multibin in mind too: for example an ABI may perform |
| 27 |
better than another one on specific workflows (x32) and it may make |
| 28 |
sense to use this abi for a specific binary (which would be manually |
| 29 |
built for now). |
| 30 |
|
| 31 |
Alexis. |
Archives