yum error of extras

[Michael Schwendt]

On Fri, 17 Dec 2004 13:58:16 +0100 (CET), Dag Wieers wrote:

> On Fri, 17 Dec 2004, Michael Schwendt wrote:
> 
> > On Fri, 17 Dec 2004 10:13:29 +0100 (CET), Dag Wieers wrote:
> > 
> > > On Thu, 16 Dec 2004, Michael Schwendt wrote:
> > > > On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:
> > > > > On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
> > > > >
> > > > > > Results follow:
> > > > > > .....
> > > > > > --> Running transaction check
> > > > > > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for package:
> > > > > > aalib-devel
> > > > > > ValueError: invalid literal for long(): %{epoch}
> > > > > 
> > > > > Looks like garbage in the epoch field of aalib.
> > > > > 
> > > > > I'll take a look at both yum and the pkg.
> > > > > 
> > > > > could you open a bug on this?
> > > > 
> > > > Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
> > > > %epoch still used. Fixed.
> > > 
> > > Ah, sweet irony.
> > 
> > No irony here, just an incomplete change and commit by somebody.
> 
> The irony is that it still bites almost 2 years after nobody wanted to 
> have it in the first place and it still ended up in the official policy 
> because of a misinterpreted JBJ comment. Simplicity and implicitly.

No, no, no. It does not. aalib and aalib-devel were working fine.
Just imagine that the package had had "Epoch: 1" already.

Look at the CVS diff between revision 1.3 and 1.4. Matthias dropped
"Epoch: 0" while doing a version bump, but forgot to drop %epoch in
the rest of the same file. The package broke itself.

This has nothing to do with old discussions on explicit Epoch.

Btw, there are people who think it is a mistake to drop "Epoch: 0"
again. So until there will be a policy about this, you will see
packages which keep the explicit Epoch and others where packagers drop
it. What a weird world we live in. :)