On Sat, Aug 19, 2006 at 02:27:16AM +0200, Andreas Hanke wrote:
Hi,
Robert Schiele schrieb:
Sure, latest SUSE shipped version _is_ 1.9.6.
But if this is a problem for people, then the same patch for the latest and greatest:
It's not a problem for me, but it would be a problem for upstream, and it has to go upstream, otherwise it doesn't make any sense - see below for reasons.
Thanks for the updated patch.
If someone sends this patch there now, this is easy. Otherwise I will send in about 10 days when I am back at home again and have the time to read all the mailing lists. If someone else sends it, I will be reachable by mail, just don't want to send something to mailing lists I currently don't read.
The patch needs to be extended to cover the texinfo documentation and the testsuite as well. That is not difficult to do, but it should be done before posting the patch there.
I will look into that later then.
It can be used even when the upstream integration process has not been completed because it is in my opinion a much better solution than the current script, even when the patch is not yet in upstream code.
No, see Stephan Kulow's post: That would break compatibility for those users who install a newer automake version from the upstream tarball. The self-installed automake would no longer find the GNOME macros.
This currently works, ironically thanks to SuSEconfig, but would no longer work with this patch instead of SuSEconfig unless the patch is included upstream.
No, if you replace the SUSE version of automake with another one you also lose the SuSEconfig.automake file because it is part of the SUSE automake package. And apart from that: If someone replaces vital parts of the toolchain without having a clue about the effects and how to fix these problems then he definitely will run into much more harmful problems than the dirlist thing.
Sure we need an extension mechanism for that. What do you think was the reason for implementing this dirlist stuff in aclocal at all?
Actually I think that the reason for implementing it with SuSEconfig was laziness. It is a very ugly solution because it breaks using the dirlist file for local settings, the user is forced to use a SUSE-only dirlist.d/* file.
So the "new" implementation is better. It allows using both variants.
Per se, it is not a bad feature at all, but a quick search on http://rpm.pbone.net for dirlist.d shows that it's currently really SUSE-only, which is bad. I was not aware of that when proposing this change.
I don't see why it is bad because of that. I mean someone _had_ to invent it. Inventions are not done by doing everything the same way all other people do it.
In my opinion it is a desired feature. It should be made a non-SUSE-only feature but as long as mainstream does not have it it does not really hurt because we had it anyway up to now by the script and nobody is forced to use it.
As long as upstream automake reads only the dirlist file and not the dirlist.d directory, SuSEconfig is the better solution and dropping it would hurt those who update to an upstream version. So we really need either SuSEconfig or this patch in upstream CVS, but not this patch as a SUSE-only replacement for SuSEconfig.automake.
I disagree. See above. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."