On Jul 4, 2008, at 11:46 PM, Alexey Tourbin wrote:

> On Fri, Jul 04, 2008 at 09:48:19PM -0400, Jeff Johnson wrote:
>>>  +	    if (!N1) headerNEVRA(h1, &N1, NULL, NULL, NULL, NULL);
>>>  +	    if (!N2) headerNEVRA(h2, &N2, NULL, NULL, NULL, NULL);
>>>  +	    rpmlog(RPMLOG_WARNING,
>>>  +		   _("file %s is packaged into both %s and %s\n"),
>>>  +		   fn1, N1, N2);
>>>
>>
>> This paradigm of displaying N-V-R.A (or whatever is deemed  
>> informative)
>> is an obviously (duh!) widely repeated paradigm throughout rpm.
>
> As for me, I think that displaying N-V-R.A is (sometimes) nothing more
> than displaying redundant information.  Here is why.  Suppose that we
> store rpmbuild build logs in some SCM system (well, we do), to study
> e.g. new compiler warnings or something.  And then, simply changing  
> the
> release is going to introduce quite a few changes in the build log,  
> and
> hence this will yield new diff hunks.  Now guess what.  When studying
> build logs, the last thing we need is those funky new diff hunks.

I don't disagree.

However, note that rpm now supports identically named packages
w different versions in the same build. Consider the error msg ...

And before multilib, noone really cared whether arch was displayed.

And before disttag & repotag & other forms of branding carried in  
release,
noone really cared about release.

Luckily, the mysterious epoch is still mysterious.

So there is no one answer.

What exists instead is RPMTAG_NVRA, a configurable means
to access metadata in headers for package identification.

73 de Jeff