Undefined %epoch problem (Re: rawhide report: 20150730 changes)

[Tomas Mlcoch]

----- Original Message -----
> On Tue, 1 Sep 2015 11:58:07 -0400 (EDT), Tomas Mlcoch wrote:
> 
> > RPM itself expects epoch to be number:
> > https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/lib/rpmvercmp.c#L124-L143
> > 
> > YUM expects epoch to be integral number:
> > https://github.com/rpm-software-management/yum/blob/e17424b34ed8409803b5e702b24f6d0051ca99ca/yum/rpmsack.py#L922
> > 
> > Fedora's doc states that "Epoch" is numeric field:
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs
> > 
> > This rpmbuild acceptance of a non-numerical epoch is obviously a bug.
> > I would prefer one of my proposed solutions instead of accepting
> > non-numerical epoch values.
> >
> 
> It is beyond my time and energy to "fight" bad package updates that don't
> fix the problem:
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-2015-735f979d01
> 
> What the new createrepo_c in that update does, it ignores the broken
> Requires altogether, skips it and doesn't add it to the repo metadata [1].
> 
> Effectively, it hides the problem even more than before when it replaced
> the unescaped RPM macro with a '0', changing the dependency on-the-fly,
> pretending that there is no problem when in fact it's broken in the binary
> package that cannot be installed.
> 
> Hiding such breakage from the metadata hides it also from depsolvers and
> tools like repoclosure that work on the metadata themselves before passing
> a transaction to RPM. They would _not_ be able to find such a problem.
> 
> IMHO, this is bad as before. I cannot estimate how often an unescaped
> epoch macro will break deps in the future again, but a package like that
> should not be published with repo metadata pretending that everything
> would be fine. If you fear that createrepo_c exiting with error condition
> *instead* would happen too often, then apparently the problem is perceived
> as an even worse one. Hard to believe.
> 
> The corresponding RFE for "rpm" is: https://bugzilla.redhat.com/1251453
> 
> [1]

Michael,

few points:

1)
There were several points of failure:
* Developer who made a typo in spec file which results into bad dependency.
* rpmbuild which built an rpm with broken dependency.
* Fedora's automated depcheck that wasn't able to find the dependency issue.
Why still ranting about createrepo_c?

2)
Why are you saying that createrepo_c is hiding the issue?
That's a lie. After the problem was discovered, I wrote a patch
which added a warning that informs user about such suspicious dependency.

3)
I wrote a rationale why I choose the approach where createrepo_c
doesn't exit immediately with error here [2] and here [3].

You have never commented on the rationale, you are just keep
saying that the approach is wrong. I'll repeat my points again:

*) createrepo_c tends to be part of critical systems for delivering
updates - I just cannot break whole update system and require
manual releng action just because some maintainer of some foobar
package did a typo in spec of package which is used by two people
in the world (where one is the maintainer itself and the second
one is a person who installed it by mistake). 

*) Dependencies like "suggests", "enhances", etc. are not important
and break whole update infrastructure because there is some
optional package with a broken dep that is optional is not good.

*) The approach you are fighting for - exit when a package has a
bad dep - in the current state of things (see 1)) would be a HUGE
SECURITY ISSUE for fedora update system.
Anyone could build a package with intentionally broken dep and
block ALL updates for WHOLE fedora for ALL fedora users.
He would just build a package with broken dep, send it directly to
fedora stable (skip fedora updates) repo and then.. whole
fedora stable repo generation would be doomed and manual
releng action would be required.

I don't know if you don't see these security aspects or if you don't
consider them important. But I won't to be the one who will introduce
a security issue to Fedora update infrastructure.

Tomas


[1] https://github.com/rpm-software-management/createrepo_c/commit/3fd1fa5020025fc62440ac8ef977fda7b087bdb5#diff-77d6596729af517434dc3b649b5251ecR386
[2] https://lists.fedoraproject.org/pipermail/devel/2015-August/213882.html
[3] https://bodhi.fedoraproject.org/updates/createrepo_c-0.9.1-1.fc22#comment-342067