The gentooalt-m4 package contains two m4 macro files that are used to patch
autotooled package to behave correctly on Gentoo/ALT ports. See the URL.
I'm asking arches to keyword this package because I have fixes (in gentoo-alt
overlay) for cups and netatalk that involves the use of this package as
dependency, so this must be keyworded before I can proceed to submit those
fixes to maintainers.
Thanks in advance to everyone.
Since its at autotool level, I do not see why the patch can include the macro as
Yes it can, but I'd rather use this method mainly for two reasons:
a) adding the m4 to the patch for every package that needs them (cups and
netatalk are just two "proof of concept" to try it out, but other packages
will follow in the future, as this fixes the -Wl,-z,now thing for macos and
other operating systems) would probably mean adding a lot of redundant code
that increases the size of the tree
b) having the m4 in a centralized package allows to update it to work for new
linkers/situations without having to update all the patch out there
You can put the patch on the mirrors if that is an issue. What I want to know
is if this 'fixes' will be going upstream or not ...
Well then you increase the size of the tree instead of using a single
And yes, the idea behind this kind of patching is that it can go upstream.
Problem is, netatalk upstream seems deadish, and I'm not really sure about who
should I try to contact for cups.
In case they go upstream, it would be handy to continue using this package and
removing the shipped .m4 to allow adding more supports just updating this
(In reply to comment #4)
> Well then you increase the size of the tree instead of using a single
> repository :)
> And yes, the idea behind this kind of patching is that it can go upstream.
> Problem is, netatalk upstream seems deadish, and I'm not really sure about who
> should I try to contact for cups.
> In case they go upstream, it would be handy to continue using this package and
> removing the shipped .m4 to allow adding more supports just updating this
> package itself.
Do not really see the need for this, as you will only need the .m4 if you gonna
autoreconf it, so upstream will ship it anyhow. And instead of you guys doing
it per alt-arch, its once again starting to become the 99% of the rest of
Gentoo's problem type thing.
(In reply to comment #5)
> Do not really see the need for this, as you will only need the .m4 if you
> autoreconf it, so upstream will ship it anyhow. And instead of you guys
> it per alt-arch, its once again starting to become the 99% of the rest of
> Gentoo's problem type thing.
The problem is that if we start using it just conditionally for gentoo-alt
arches, we need two patches for every package, one that add -Wl,-z,now for
Linux, and one that uses the m4 for gentoo-alt. And this doesn't seem too good
Also, if something changes in the m4, using a single package the fix is
trivial, while if we have to send the patch to every maintainer, we might
require tenths of bugs and different maintainers to fix the same thing...
It seems more practical, to me, spending a bit more time keywording/bumping
the m4 package instead of having to resend the patches everytime..
upstream tends to not accept bind now flags in their packages
why is m4 better than patching in say @BIND_NOW_FLAGS@ and then just running
`sed -i -e "s:@BIND_NOW_FLAGS@:$(bindnow-flags):" Makefile.in`
Because the m4 is pushable upstream.
Why you say that they usually refuse them?
If you think that those patches should not go upstream, I'm fine with your
solution and I can take down gentooalt-m4 entirely.
Close this bug if you think so, and I'll act according.
I'll go with vapier's idea then, using patch + sed . The package is going away
soon. Sorry arches for the noise.