Jeff Spaleta wrote:
On Tue, 1 Feb 2005 16:12:14 +0000 (GMT), Mark J Cox <mjc@xxxxxxxxxx> 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
