Re: Next upload 2009-05-18 (dpkg 1.15.1)
On Sun, 2009-05-17 at 16:20:41 +0200, Raphael Hertzog wrote:
> On Sun, 17 May 2009, Guillem Jover wrote:
> > * dpkg vendor env settings.
> >
> > Now that Raphaël has implemented the dpkg-vendor program, those vars
> > can be disabled w/o any problem.
>
> Done.
Cool, thanks.
> > * Build flags env settings.
> >
> > Raphaël mentioned on IRC that we could wait a bit for this, but I
> > think we rather stop exporting them now so that no more maintainers
> > start relying on them. We can always reenable them later on if we
> > end up deciding this is the way to go.
>
> 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.
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
discussion.
> Also why should we keep the dpkg-architecture environment variables if we
> decide that using environment variables in not a good idea ?
I explained that in my mail to d-d. We can certainly remove them, as I
know that bugs have been filed whenever packages were not properly
initializing those variables in debian/rules.
The difference is that because there's no need to append to the
environment variable it does not get duped content, which does not
prompt maintainers to remove the variables from the rules file. The
documentation mentions that they should be initialized in the rules
file. And also the values are not really something the packages should
be choosing, the build system is static and the host system depends on
the toolchain.
> > * Build flags to be overriding via cmdline instead of env.
> >
> > And I considered this a blocker initialy, but I don't think it
> > matters if we don't set any variable by default. And other distro
> > might want to use this behaviour for now, even if it only affects a
> > small proportion of the packages anyway. So we can leave it for
> > latter.
>
> I fail to see why it would be a blocker when the current behaviour is
> in a stable release of Debian.
I just wrote here I didn't consider it a blocker, I guess it might
have seemed confusing due to the placement in the bulleted list, sorry
about that. I mentioned it here because I said on d-d that I'd like to
get this changed before the upload.
But then I don't see how having something on a stable release
justifies keeping it if it happens to be a broken behaviour. In this
case it would not really be broken (per current policy) if it was not
setting env vars by default, either way it's mostly not that useful
currently as only a really small fraction of packages honour the build
flags from the environment.
Anyway, if we have to discuss about the env settings, probably better to
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.
JFTR, I would not have any problem with the current behaviour if we reach
consensus this is the way to proceed, and policy is updated to reflect
that. I'm just not confortable with this being pushed as an
implementation's side-effect.
> > * Private field prefix.
> >
> > Sent a mail already.
>
> I didn't reply as I don't care much. I have no problem with either
> solution.
>
> I find the X- prefix much more common and clear, it's just a matter of
> having good documentation.
Ok, I've the patch now, but I'll think about it a bit more before
committing.
regards,
guillem
Reply to: