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. Diego
Since its at autotool level, I do not see why the patch can include the macro as well?
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 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.
(In reply to comment #4) > Well then you increase the size of the tree instead of using a single > repository :) > Ok? > 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 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. 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 for maintainers. 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?
experience
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.
