Re: [gentoo-dev] Rethinking multilib flags in Gentoo

[Michał Górny]

On Wed, 2019-05-08 at 11:54 +0200, Alexis Ballier wrote:
> On Wed, 08 May 2019 11:41:41 +0200
> Michał Górny <mgorny@g.o> wrote:
>
> > > There's multilib that adds a lot of flags with a single eclass
> > > change, but I'd guess the number of packages and flags is
> > > constantly growing, so sooner or later you'll be hit by this again
> > > and no multilib killing will help you then.
> > >
> > > I think it is more future proof to use the addition of multilib
> > > flags to fix pkgcheck rather than actively reducing the number of
> > > multilib flags to cope with its limitations.
> >
> > Then please do it, by all means.  The reality is simple.  If the tool
> > is broken, you either fix it or stop doing what you know that breaks
> > it. Being unable to do the former, and having no good replacement,
> > I'd go for the latter.
>
> Well, why is it slow ? IO ? CPU ? Did you collect profiling data ?

CPU definitely.  More detail than that, I don't and I don't have time to
investigate.

> Where are the scripts to repro the issue ?

https://github.com/mgorny/pkgcore/tree/repo-mirror-ci
https://github.com/mgorny/pkgcheck/tree/repo-mirror-ci

(repo-mirror-ci branch in both cases)

I suppose master branch suffers from the same problem but I didn't find
time to check (and it is not very helpful until I find time to rebase
all my fixes that weren't merged before refactoring everything).

> > > Also, remember that multilib is not entirely about skype or slack,
> > > this was made with multibin in mind too: for example an ABI may
> > > perform better than another one on specific workflows (x32) and it
> > > may make sense to use this abi for a specific binary (which would
> > > be manually built for now).
> >
> > No, it weren't.  Just because someone found it convenient to use the
> > design beyond its original purpose doesn't mean it had a different
> > purpose.  Besides, how many 'multibin' packages do we have right now?
>
> It was, because portage multilib was doing this and claimed to have a
> use for this.

I am not talking of 'portage multilib'.  I am talking of multilib-build
implementation.  If you are only concerned about the former, we can
surely drop those abi_* flags that are irrelevant to it, can't we?

>  Its original purpose was generic enough to allow multibin
> to be added easily. The number of multibin packages is only
> relevant to show that this is not important enough for someone
> to step up and do it: Everybody can easily build anything themselves
> with the current implementation.

Exactly.  And that's why I believe having fast CI is more important than
DIY multibin.  If someone can 'easily build anything themselves', they
can also add needed flags locally.


-- 
Best regards,
Michał Górny