Comment 6 for bug 377584

Matthias Klose (doko) wrote :

<doko> pitti: would you mind explaining for #377584 what you are missing?
<pitti> doko: see comment 5
<doko> pitti: what don't you understand in comment 4?
<pitti> doko: well, "not expanding ${prefix}" doesn't really describe a bug or a fix, or why it is critical to update this in stables
<doko> pitti: because it restores autoconf's upstream behaviour
<pitti> doko: so it was broken in jaunty?
<pitti> doko: an SRU has to demonstrate what's broken, and how to test it
<doko> it doesn't matter for jaunty, but it does matter for autoconf generated scripts which are used outside of Ubuntu
<pitti> right now there is no way to tell the severity, how to verify an update, and what potential breakage it has for jaunty
<doko> pitti: run a configure script generated by autoconf with and without the patch. I assume that should be enough to demonstrate the behaviour
<pitti> right, and exactly this kind of information is missing
<pitti> - example configure script (or package, or URL to upstream project, etc.)
<pitti> - if I use teh jaunty automake, what breaks?
<pitti> - the update fixes that breakage, how should its output/behaviour look like?
<pitti> - how did it behave in hardy/intrepid? when did it regress?
<pitti> doko: ^
<doko> pitti: sorry that's pedantic. I'll paste this to the bug report.
<pitti> doko: pedantic? right now there is nothing in that bug report that tells _anyone_ why this SRU is necessary
<pitti> and I'm not going to accept a basic toolchain change into a stable release without at least some justification and test cases
<pitti> (and yes, SRUs need to be pendantic by definition)
<doko> pitti: there is: it's a no change for building packages in Ubuntu, but brings the python packages back in sync with the upstream behaviour not expanding ${prefix} and ${exec_prefix}
<doko> and it does exactly decribe the change
<pitti> right, the techical implementation ("not expand blabla"), but not the actually visible behavioural change/impact/justification
<pitti> and unless someone can actually test it, this won't ever go to -updates

how to reproduce:

 - run a configure script with the AM_PATH_PYTHON macro expanded
 - check the output that PYTHON_PREFIX and PYTHON_EXEC_PREFIX
   start with the unexpanded ${prefix} and ${exec_prefix} macros.