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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

Hi, everyone.

Since the bug about libtool.eclass [1] has not received any attention, I
hereby declare maintainer timeout and start working on improving
the eclass.

The main goals are to:

a. stop requiring every single autoconf ebuild to call elibtoolize
manually (and effectively having half-'broken' repository),

b. stop bundling the large number of patches with the repository,

c. stop using hacks to find those patches.

The planned steps are to:

1. split epunt_cxx out of eutils:

1.1. split the function into new eclass (PATCH already sent),

1.2. explicitly inherit the new eclass in all ebuilds using epunt_cxx,

1.3. remove implicit inherit from eutils,

1.4. move patches to a package and make the new eclass DEPEND on it.

2. move patches to a package and make libtool.eclass DEPEND on it.

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.

4. when new Portage goes stable, start killing libtool.eclass.

Any comments?

[1]:https://bugs.gentoo.org/show_bug.cgi?id=566424

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alexis Ballier]

On Fri, 17 Mar 2017 18:14:12 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> Since the bug about libtool.eclass [1] has not received any
> attention, I hereby declare maintainer timeout and start working on
> improving the eclass.
> 
> The main goals are to:
> 
> a. stop requiring every single autoconf ebuild to call elibtoolize
> manually (and effectively having half-'broken' repository),
> 
> b. stop bundling the large number of patches with the repository,
> 
> c. stop using hacks to find those patches.
> 
> The planned steps are to:
> 
> 1. split epunt_cxx out of eutils:
> 
> 1.1. split the function into new eclass (PATCH already sent),
> 
> 1.2. explicitly inherit the new eclass in all ebuilds using epunt_cxx,
> 
> 1.3. remove implicit inherit from eutils,
> 
> 1.4. move patches to a package and make the new eclass DEPEND on it.
> 
> 2. move patches to a package and make libtool.eclass DEPEND on it.
> 
> 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.


Define it in a new EAPI. Make elibtoolize die in EAPI supporting
auto-elibtoolize.

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Fri, 17 Mar 2017 18:14:12 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> Since the bug about libtool.eclass [1] has not received any attention, I
> hereby declare maintainer timeout and start working on improving
> the eclass.
> 
> The main goals are to:
> 
> a. stop requiring every single autoconf ebuild to call elibtoolize
> manually (and effectively having half-'broken' repository),

Good! This will help immensely with cross-compiling.

> 1.1. split the function into new eclass (PATCH already sent),

The function itself is quite complex. Perhaps this should also go into
a separate package?

> 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.

Back in September, I tried turning the eclass into an external script
with very few changes to start with, just as a proof of concept. I
removed the few references to other eclass helpers but still retained a
little dependence on variables exported by Portage. I then stuck a call
to this to near the top of econf() and tried out some packages,
including those that had failed on me before. It worked very well
indeed. I don't recall encountering any issues.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

On pią, 2017-03-17 at 23:38 +0000, James Le Cuirot wrote:
> On Fri, 17 Mar 2017 18:14:12 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Hi, everyone.
> > 
> > Since the bug about libtool.eclass [1] has not received any attention, I
> > hereby declare maintainer timeout and start working on improving
> > the eclass.
> > 
> > The main goals are to:
> > 
> > a. stop requiring every single autoconf ebuild to call elibtoolize
> > manually (and effectively having half-'broken' repository),
> 
> Good! This will help immensely with cross-compiling.
> 
> > 1.1. split the function into new eclass (PATCH already sent),
> 
> The function itself is quite complex. Perhaps this should also go into
> a separate package?

Are you talking about epunt_cxx or elibtoolize now? (this point was
about epunt_cxx)

If the latter, yes, I think it makes sense to split the patching logic
into a separate script.

> > 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.

> Back in September, I tried turning the eclass into an external script
> with very few changes to start with, just as a proof of concept. I
> removed the few references to other eclass helpers but still retained a
> little dependence on variables exported by Portage. I then stuck a call
> to this to near the top of econf() and tried out some packages,
> including those that had failed on me before. It worked very well
> indeed. I don't recall encountering any issues.

Nice, that was exactly my plan. I'll create a git.g.o repo for this
in a few days, and commit the patches there. Would you be interested
in working on splitting the script again/updating your stand-alone
version?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alexis Ballier]

On Sat, 18 Mar 2017 07:53:31 +0100
Michał Górny <mgorny@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.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

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@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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alexis Ballier]

On Sat, 18 Mar 2017 11:21:58 +0100
Michał Górny <mgorny@gentoo.org> 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@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.

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.

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

[Peter Stuge]

Alexis Ballier wrote:
> > 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,

Where are those patches you mention?


> I could fine one fixing relink to old libs (from / instead of $D),

I have an open bug for this for a package, both in Gentoo and
upstream. It seems to be a problem with libtool itself, is that
about right?


> 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.

What "this" do you refer to? Sorry for the confusion, I want to understand.


//Peter

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

[Alexis Ballier]

On Sat, 18 Mar 2017 19:29:36 +0000
Peter Stuge <peter@stuge.se> wrote:

> Alexis Ballier wrote:
> > > 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,  
> 
> Where are those patches you mention?

Those in ELT-patches...

> > I could fine one fixing relink to old libs (from / instead of $D),  
> 
> I have an open bug for this for a package, both in Gentoo and
> upstream. It seems to be a problem with libtool itself, is that
> about right?

With recent libtools it is most likely to be the package's fault, like
wrong/poor usage of autotools.


> > 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.  
> 
> What "this" do you refer to? Sorry for the confusion, I want to
> understand.


the bugs