----- 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
