| 1 |
On Fri, 17 Mar 2017 18:14:12 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Hi, everyone. |
| 5 |
> |
| 6 |
> Since the bug about libtool.eclass [1] has not received any |
| 7 |
> attention, I hereby declare maintainer timeout and start working on |
| 8 |
> improving the eclass. |
| 9 |
> |
| 10 |
> The main goals are to: |
| 11 |
> |
| 12 |
> a. stop requiring every single autoconf ebuild to call elibtoolize |
| 13 |
> manually (and effectively having half-'broken' repository), |
| 14 |
> |
| 15 |
> b. stop bundling the large number of patches with the repository, |
| 16 |
> |
| 17 |
> c. stop using hacks to find those patches. |
| 18 |
> |
| 19 |
> The planned steps are to: |
| 20 |
> |
| 21 |
> 1. split epunt_cxx out of eutils: |
| 22 |
> |
| 23 |
> 1.1. split the function into new eclass (PATCH already sent), |
| 24 |
> |
| 25 |
> 1.2. explicitly inherit the new eclass in all ebuilds using epunt_cxx, |
| 26 |
> |
| 27 |
> 1.3. remove implicit inherit from eutils, |
| 28 |
> |
| 29 |
> 1.4. move patches to a package and make the new eclass DEPEND on it. |
| 30 |
> |
| 31 |
> 2. move patches to a package and make libtool.eclass DEPEND on it. |
| 32 |
> |
| 33 |
> 3. copy elibtoolize logic to Portage, and make it apply implicitly |
| 34 |
> on econf [do we need to apply it elsewhere?]; disable explicit |
| 35 |
> libtoolize when Portage supports that. |
| 36 |
|
| 37 |
|
| 38 |
Define it in a new EAPI. Make elibtoolize die in EAPI supporting |
| 39 |
auto-elibtoolize. |
Archives