Re: New make is breaking several packages
Manoj Srivastava <firstname.lastname@example.org> wrote:
> On Wed, 28 Dec 2005 18:24:14 +0100, Frank Küster <email@example.com> said:
>> Frank Küster <firstname.lastname@example.org> wrote:
>> Sorry that i didn't check this - I thought that you, Daniel, were
>> the make maintainer (thanks Adeodato). The rest of my statement
>> still holds,
>>> should consider such a change thoroughly and in fact test
>>> alternatives *before* the release or upload.
> I generally do not respond to such clieless inanities, but I
> am feeling generous today. What on earth makes you think that POSIX
> compliance was not thought about thoroughly? Or did you make that
> asserion up out of thin air?
I don't think that the change was made without thoroughly thinking about
it. But in fact it seems as if there are no instructions for
transitioning Makefiles that rely on the old behavior, be it
non-POSIX-compliant or not. And I think such an instruction should have
been given - not by you, but already by upstream.
> And this bit about testing displays a distinct lack of
> experience about real work testing experiences; in fact, the new make
> works just fine on all my packages, and did not have any deleterious
> bahviour change for them -- this is like 30 or so source packages.
Err, it seems to have broken other packages. Even telling people "most
cases where line continuation is used will work just fine with both
versions" would be a valuable piece of information; right now we have
only some complaints, a proposed workaround that brakes with older make
versions, and a new proposal which probably works with both, but has not
Well, I tested it, and it doesn't work:
frank@sarge$ cat Makefile
frank@sarge$ cp Makefile /sid/home/frank/
So it seems that it is not possible to make shell commands with line
continuation work with both make versions, and one has to resort to the
make variable solution.
>>> And a sarge or even woody pbuilder chroot is just a couple of
>>> commands away. Probably you can even install sarge's make_...deb
>>> in a sid or etch chroot.
> More inanity, which I shall ignore.
Excuse me, that wasn't directed at you, but at Daniel who said he had no
sarge for testing (but when I thought that he was the maintainer)
> This shall get into the next upload.
> BTW, this is "UNSTABLE". If you can't deal with changes in
> behaviour of unstable right when we are in a high development phase,
> run Sarge. Or stop the pontification.
I have no problem currently in sid (and I do run sarge on my main
working machine). But I'd like to provide backports.
Inst. f. Biochemie der Univ. Zürich