rpm-epoch0.patch
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
earlier
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