Re: Next upload 2009-05-18 (dpkg 1.15.1)
On Tue, 19 May 2009, Guillem Jover wrote:
> > I would rather wait a final decision on this instead of knowingly breaking
> > packages once more. Not sure how to reach a decision, the discussion is
> > rather slowly paced. Maybe asking a recommendation to the technical
> > committee ?
> Well, to me the main reason is that those packages are already broken
> per policy, and this is just to avoid even more breakage.
Well, there's "broken per policy" and "broken as in mis-compiled".
Removing the variables without informing maintainers in time will
lead to the latter. Right now we only have the former.
So I'm ok to remove them but not without advance warning on d-d-a.
> I'll be writting another summary for d-d with the new stuff discussed
> there. Let's see if we can progress or at least agree on parts of the
It looks like the solution lies probably in a new tool dpkg-buildopt
that debian/rules can use to obtain the build flags.
We can also provide Makefile snippets that do stuff like that:
CFLAGS := $(shell dpkg-buildopt CFLAGS)
LDFLAGS := $(shell dpkg-buildopt LDFLAGS)
That could simplify the work of maintainers (and at the same time we
should provide makefile snippets for providing the other interesting
variables related to dpkg-architecture and dpkg-vendor).
> But then I don't see how having something on a stable release
> justifies keeping it if it happens to be a broken behaviour.
I was not justifying to keep it, I was simply giving another reason
why I agree that it should not be a blocker.
> continue on the existing thread. Also I understand your desire to wait a
> bit before disabling the settings by default, and I'd be fine with
> delaying the change until say 1.15.2 to give some time to maintainers
> with broken packages to fix them. But not by delaying it indefinitely
> until we reach a decission while dpkg-dev is promoting policy violations
> and more packages might get changed due to this.
I hope we can reach some sort of decision soon. I want to see this
resolved and don't want to promote policy violations by delaying it.
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :