Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

[Alexis Ballier]

On Sat, 18 Mar 2017 11:21:58 +0100
Michał Górny <mgorny@g.o> wrote:

> On sob, 2017-03-18 at 11:18 +0100, Alexis Ballier wrote:
> > On Sat, 18 Mar 2017 07:53:31 +0100
> > Michał Górny <mgorny@g.o> wrote:
> > > > > 3. copy elibtoolize logic to Portage, and make it apply
> > > > > implicitly on econf [do we need to apply it elsewhere?];
> > > > > disable explicit libtoolize when Portage supports that.
> > > >
> > > > Related to the above point, if you make it part of econf then it
> > > > needs to be part of PMS and that's quite a complex beast to
> > > > have in the spec. It has been suggested twice on this list
> > > > (once quite recently) that the script itself should put into a
> > > > separate package for this reason. Then PMS just needs to say
> > > > "install and use this script" without any further detail.
> > >
> > > Strictly speaking, you don't have to have it in the PMS. This can
> > > be left purely as Portage extension, much like gnuconfig hacking
> > > is right now.
> >
> > Having different portage versions or different PM behaving
> > differently for the same ebuild and portage tree, producing
> > different binaries, definitely defeats PMS goals. If such things do
> > not need to be in PMS then I don't know why we even have PMS in the
> > first place.
>
> If elibtoolize results in different binaries being produced, then it's
> done wrong in the first place. AFAIU the primary goal of elibtoolize
> logic is to fix issues on recent systems with outdated build systems.
> Which is certainly not something that needs to be done for every user
> out there.

You probably didn't have a look at what the patches fix. Having a
quick look at patches there, I could fine one fixing relink to
old libs (from / instead of $D), another one fixing parallel install.
The former produces broken binaries, the latter none at all.

I seriously doubt this shouldn't be fixed for every user.