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

Michael Schwendt mschwendt at gmail.com
Thu Oct 22 14:11:18 UTC 2015

On Thu, 22 Oct 2015 08:41:58 -0400 (EDT), Tomas Mlcoch wrote:

> 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?

You detect invalid input data => you exit with error condition.
Easy as that.

Eventually, the problem may be detected earlier. E.g. by rpmbuild.

Would Taskotron/AutoQA be capable to detect it? It does provide means
to examine binary rpms, doesn't it? How else could it run rpmlint?
How much effort would it be to run createrepo_c on the binary rpms
and reject them if createrepo_c complains?

> 2)
> Why are you saying that createrepo_c is hiding the issue?
> That's a lie.

No, the tool is lying.

The tool creates metadata that passes repoclosure when in fact the
packages in the repo contain a dependency that cannot be resolved.

Turning a string "%{epoch}" into "0" is hiding the invalid input data.

By definition, no Epoch in versioned dependencies is equal to Epoch 0.
The tool replaces am unresolvable dependency with a resolvable one.

The new "fix" is hiding the issue, because it deletes an entire "Requires"

> After the problem was discovered, I wrote a patch
> which added a warning that informs user about such suspicious dependency.

Which user? Who would watch out for such a warning in koji, Copr and
other build systems?

> *) 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.

Do you realize I've opened an RFE for "rpm" in August already?

> Anyone could build a package with intentionally broken dep and
> block ALL updates for WHOLE fedora for ALL fedora users.

Anyone? No. Only existing packagers. And for how long? And nobody would
notice and remove the package?

With that perspective, an existing packager can attack the infrastructure
in other ways, too. It's possible to break buildroot creation. It's
possible to obsolete packages you don't own.

> 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.

Ridiculous. Running createrepo_c on individual updates would be very
fast and would ensure they are not rejected by createrepo_c.

You're trying much to approach the problem for the wrong side, IMO.

More information about the devel mailing list