Jeff Johnson n3npq at mac.com
Tue Feb 19 21:28:32 CET 2008

On Feb 19, 2008, at 2:56 PM, Elan Ruusamäe wrote:

> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/rpm-epoch0.patch
> should we still keep this patch?

Depends. Looking forward, the right fix is to add a header
extension to always return Epoch: 0 when the tag is missing.
I've not added because header extensions get very mysterious,
someone like mis or arekm will waste a lot of time trying
to figure how Epoch:0 is returned even though its not present
in a package.

Looking backward, there was a a single weird corner case in 4.4.2 and  
where the existence (or not) of an explicit Epoch: 0 changed behavior.
The problem with adding Epoch: 0 to headers always is that rpm will
be forced to carry RPMTAG_EPOCH forever once it starts getting
automagically added. I'm trying to phase out RPMTAG_EPOCH, which
is necessary, but invariably used too often to band-aid other problems.

> why it's needed in first place anyway?

Why is Epoch: needed? package management needs some
internal means to override broken version-release choices. Note
"internal", putting an explicit Epoch: everywhere publically because
of a few broken version-release choices is the wrong way to
solve the problem. A better way would be to hav a means to
alter version-release in dependencies if/when broken.

> ps: i still see (old) packages built in ac without epoch:
> $ rpm -qa --qf '%{epoch}\n' |sort |uniq -c | sort -nr
>     997 0
>     196 1
>      69 9
>      50 (none)
>      48 2
>      31 3
>      18 5
>      17 4
>      17 10
>      15 6
>       7 8
>       4 7
>       3 13

Yes, you will see with --qf because I have not added the
header extension for epoch. If I add the extension, then
epoch will always be 0, and you will have no means to tell
whether Epoch: is really zero or just missing using --query.

Meanwhile, on all internal code paths that I know of, 0 is returned
when epoch is missing.

I'd personally drop the patch if I were you. There are better answers to
any problems that appear.

73 de Jeff

More information about the pld-devel-en mailing list