On sob, 2017-03-18 at 11:18 +0100, Alexis Ballier wrote: > On Sat, 18 Mar 2017 07:53:31 +0100 > Michał Górny <mgo...@gentoo.org> 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. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
