| 1 |
On Thu, 2021-09-02 at 12:46 +0200, Michał Górny wrote: |
| 2 |
> Signed-off-by: Michał Górny <mgorny@g.o> |
| 3 |
> --- |
| 4 |
> eclass/apache-module.eclass | 1 + |
| 5 |
> 1 file changed, 1 insertion(+) |
| 6 |
> ... |
| 7 |
> # @SUPPORTED_EAPIS: 5 6 7 |
| 8 |
> +# @PROVIDES: depend.apache |
| 9 |
|
| 10 |
I'm not sure about this one. The depend.apache eclass is junk and we |
| 11 |
should be encouraging people to move away from it (bug 616612): |
| 12 |
|
| 13 |
* If you want to depend on apache, depend on apache. |
| 14 |
|
| 15 |
* If you need paths like APACHE_MODULESDIR, the "apxs" tool is now |
| 16 |
in PATH so you can get it from $(apxs -q libexecdir) |
| 17 |
|
| 18 |
* If you need paths like APACHE_MODULES_CONFDIR, the eclass doesn't |
| 19 |
work anyway. You can hard-code those paths yourself (relative to |
| 20 |
apxs -q sysconfdir), or if anyone feels up to the task, they could |
| 21 |
write a greatly simplified apache-paths.eclass that provides these |
| 22 |
paths via functions that are to be called outside of global scope. |
| 23 |
|
| 24 |
If people are using anything in depend.apache, I think a warning is |
| 25 |
appropriate. Making a promise that apache-module (which is not junk) |
| 26 |
provides depend.apache will moreover make it harder to disentangle them |
| 27 |
in the future if anyone decides to fix things. |
| 28 |
|
| 29 |
Disclaimer: I'm not the apache maintainer. |
Archives