radical suggestion for fc4 release

[Jeff Johnson]

Jeff Spaleta wrote:

>On Tue, 1 Feb 2005 16:12:14 +0000 (GMT), Mark J Cox <mjc at redhat.com> wrote:
>  
>
>>Right now to determine if a particular issue is fixed you need to search
>>the changelog, and if nothing is mentioned, unpack the SRPM, then look in
>>each of the patches to see if the CVE name is mentioned, and if not if the
>>patches included vaugely matches the patch for the issue.  We do this in
>>our pre-release audit - packages are horribly inconsistant.
>>    
>>
>
>
>I'm not sure how turning this into a provides garuntees consistency.
>It still comes down whether or not a packager sticks the provides in
>manually.. not much different than sticking in a note in the
>changelog. Either one is easily forgotten by a packager.  Bugzilla is
>riddled with bugs about missing provides and requires that are
>manually created by the packager. I don't see how moving it out of the
>changelog creates a consistency win.
>  
>

A packager who choses not to add the Provides: changes nothing, the 
audit will be done.

Notes in changelogs are not easily automated, nor does rpm have keyword 
indices for changelogs.

Bugzilla is riddle with missing Requires:, not missing Provides:, as 
packagers only
notice what is obvious, and an unmatched Requires: is invariably full stop.

That is not the mechanism being suggested for CAN/CVE entries.

>But please consider that by encoding this information into a provides
>you are polluting the provides namespace that depsolvers are using
>with information that you have no intention of using like a
>dependancy. This will lead to unexpected problems.. when 'some'
>packagers get the bright idea to actually do a dependancy on this,
>that depsolves will have to negotiated.  Maybe if the intent of the
>provides doesn't include using it as part of depsolving.. maybe this
>is the wrong place to encode this information.
>  
>

The provides name space is there to be used, "polluting" is bottom trolling.

73 de Jeff