Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Manoj Srivastava <srivasta@acm.org> writes:
> Previously, any new feature in dpkg which goes into release
> foo gets into policy in release foo + 1. Is there a compelling
> reason to diverge from this practice?
>
> manoj
Isn't that for binary packages because otherwise you can't upgrade
from old-stable to stable or from stable to testing/unstable anymore.
If you mean "gets used" by "gets into policy" then I don't believe
this was ever enforced for sources. For example udeb shlibs magic was
added and is used in etch. Adding -gnu and new fields to
dpkg-architecture output was added and is used in etch. And so on.
If you mean that we agree on this now, implement it in dpkg and
friends but only add it to policy after the etch release then that is
fine by me too.
But it doesn't feel right to just implement this in dpkg and then
force this into policy later or decide that we don't want this at
all. I don't think issues directly affecting policy should just be
decided by the dpkg maintainers alone
MfG
Goswin
Reply to: