[Rpm-maint] [PATCH] Allow deprecations to work accross colors (RhBug:713323)

[Ales Kozumplik]

Hi Panu,

thanks for taking time to think this over.

On 12/22/2011 02:37 PM, Panu Matilainen wrote:
> On 12/07/2011 05:17 PM, Ales Kozumplik wrote:
>> This enables package maintainers to:
>> - Force removal of a no longer supported multilib library.
>>
>> - Deprecate packages of different header color than the package's.
>
> Yup... I suppose this is the best we can do, short of introducing some
> means for packages to control the behavior. But even then packagers
> might not actually control what bits are "multilib'ed" in a distro.

Yes, I am curious to see how quickly will some packager raise this.

>> Note:
>> even x86_64 packages can have header color 1 in which case we are
>> currently left with no means to deprecate them from another x86_64
>> package. (RhBug:751574)
>
> Not in the scope of this patch, but this is actually something we
> probably should at least warn about at build-time. There are always
> going to be special cases (eg grub likely qualifies as such), but
> "normal" cases wrong colored files in packages are likely to be bugs. We
> already have such a check on noarch packages (in processBinaryFiles).

Added on my list.

> Please split the skipColor() part to a separate commit as this isn't
> related to the obsoletes behavior (in this version of the patch at least)
>

Right, extracted that.

> I'd keep the ohNEVRA local to the scopes where used for the debug output
> (it'll only get called once for any header anyway), partly because I
> prefer strict symmetry on alloc/free, partly because now it'll grab the
> nevra for every package we go through, whether used or not (and just for
> a debug output that's in 99% cases hidden anyway. It's unlikely to cause
> any measurable performance hit in this case, but some other dependency
> checking related place was wasting very measurable percentage of runtime
> generating debugging output nobody would normally see. So grumbling
> mostly just on principle here :)

Makes sense, fixed.

> Other than that, ACK.
>
> Not related to this patch, but while on the subject... the use of
> rpmdsAnyMatchesDep() seems dubious here, as that matches against
> provides whereas obsoletes are on package names. It shouldn't make a
> difference on functionality as we're iterating based on the package
> name, but using rpmdsNVRMatchesDep() would make it clearer. Plus it's
> somewhat cheaper as well since there's just one value to compare,
> whereas constructing provides dependency set and comparing is quite a
> bit more work.

I put this on my list as something to investigate.

I've pushed the corrected patches now, and started the wiki page with 
tag semantics I was talking about as I feel it is useful to set some 
things down:

http://rpm.org/wiki/TagSemantics

I plan on expanding this. If this won't prove useful (or too obvious) 
long term we can just delete it instead of linking to it from another page.

Ales