Bug#509932: shlibs format only addresses one versioning structure
Steve Langasek <vorlon@debian.org> writes:
> On Thu, Jul 01, 2010 at 12:15:38PM -0700, Russ Allbery wrote:
>> diff --git a/policy.sgml b/policy.sgml
>> index 1e641e6..9a72be5 100644
>> --- a/policy.sgml
>> +++ b/policy.sgml
>> @@ -5470,8 +5470,13 @@ Replaces: mail-transport-agent
>> <p><file>debian/shlibs.local</file></p>
>>
>> <p>
>> - This lists overrides for this package. Its use is
>> - described below (see <ref id="shlibslocal">).
>> + This lists overrides for this package. This file should
>> + normally not be used, but may be needed temporarily in
>> + unusual situations to work around bugs in other packages,
>> + or in unusual cases where the normally declared dependency
>> + information in the installed <file>shlibs</file> file for
>> + a library cannot be used. The contents of this file
>> + override information obtained from any other source.
>> </p>
>> </item>
> I think the last sentence could use some tweaking - the first time through I
> didn't even parse it as a sentence. Perhaps:
> This file overrides information obtained from any other source
> ?
Thanks, modified.
> As a side note, I think it would be good to have a longer minimum
> comment period on substantive policy changes. Two days from patch
> proposal to merge is long enough to get the requisite seconds, but I
> don't think it's long enough to establish that those seconds are a
> consensus, or to allow good counterproposals / objections. I understand
> you're working through a backlog and heartily appreciate your efforts,
> but there have been a couple patches I've seen go by recently with
> wording I thought could have been improved that were committed before I
> had a chance to react :)
I can let them sit for longer, but first, let me explain the theory and
see if that helps. My feeling on the wording changes is that since
informative changes can be made without seconds, it's easy enough to make
those changes when people raise them later, even if I've already merged
the initial patch. Also, since the only point at which we've really
committed to something is with the upload, if someone disagrees entirely
we can always reopen it and pull the patch while the discussion continues.
I can let things sit longer before merging and still work through the
backlog, though. It just increases the number of things that are in
motion at the same time, and we have fairly good ways of tracking that.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: