Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Colin Watson <cjwatson@debian.org> writes:
> I think I'd be inclined to avoid mentioning package priority at all
> here; of late it's been quite weak, and I don't think we'd want bash
> providing, say, scsh (which is extra) without some kind of notice.
Well, priority is our rule for this case.
However, maybe I agree. If you have two packages that provide the
same binary, you get notice when you try and install them. But if
it's this kind of case with a builtin, then that isn't so. So perhaps
you're right.
> Yes, this means that introducing new shell built-ins is difficult. It
> doesn't mean that they can't be done, only that, per the language of
> 10.1, the shell maintainer has to go and talk to the maintainer of the
> other package and to debian-devel and decide which one gets to keep the
> name. I think that's exactly the behaviour we want.
Agreed completely.
> test -a/-o isn't release-critical at the moment anyway.
> Release-criticality is determined by the release managers, not the
> policy manual, and this issue clearly isn't mature or agreed-upon yet
> among developers nor does it cause widespread breakage for most users.
Right. My point is that policy doesn't need to say "this is
deprecated", it can just go ahead and prohibit it; bugs can be
appropriately filed (or not); and release managers can mandate
compliance with a given version of Policy or various sections at their
option. Release-critical decisions of this sort should be made by
release managers, not by policy.
But that means that we don't need to worry about "deprecated" status
at all. :)
> The maintainers of the policy manual have always taken a similar
> attitude, so forbidding it right away wouldn't happen; rather, it would
> be a "should not" for the moment until general conformance is sorted
> out.
Yes, I'm happy to have "should not" rather than "must not" here; my
concern is to have the current situation fixed.
Thomas
Reply to: