#371 Packages approved without satisfied dependencies
Closed: Fixed None Opened 5 years ago by vondruch.

I see more often then I would like that some packages get pushed into Fedora and immediately appears among broken dependencies, since they were pushed into Fedora sooner then their dependencies.

So I propose to add one additional bullet into reviewer guidelines [1]:

"Package should have satisfied all its dependencies prior it is approved."

Hopefully somebody will notice next time during review ....

This was previously discussed on packaging ML: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009795.html


I've seen too many cases where separate people are reviewing the packages to want to vote for this as a blocker to approval. The automatic testing described in that (and previous) threads is what Fedora has always shot for. Perhaps cvsadmin could make it policy not to process SCMAdmin requests until the dependencies are done (maybe implemented by checking whether there are open blocker bugs for the package review).

We could canonicalize the common sense notion that packages must have all their dependencies satisfied before they are built and pushed to updates but since people only check the Guidelines when reviewing the package, it doesn't carry as much weight.

info Blocking a package review until all dependencies of the package are satisfied rejected (+1:1, 0:0, -1:5)

I think tibbs summed up the general sentiment with:

[09:09:24] <tibbs|w> Otherwise reviewing some dependent packages becomes even longer of a process than it is now.

We also noted that the problem is just as likely to affect package updates as it is to affect new packages.

We did pass:

info Packages should not be built unless all of their Dependencies are satisfied Passed: (+1:5, 0:0, -1:0)

although we noted that it might not help much (we think maintainers are forgetting that the dependencies aren't ready rather than not knowing that they should be waiting for deps to be present).

I read the minutes and I agree with what was said. My intention was to highlight the issue and review guidelines are IMO the most visible place (I am reading them everytime I am doing review, to not forget something). Technical solution would be better of course.

There is something to write up here: Packages should not be built unless all of their Dependencies are satisfied

I went ahead and added a little section to the end of the review guidelines. Could probably use some references but it seems to work to me. Still not sure why this was an issue at all (since, uh, the builds will fail anyway) but maybe what I wrote will clarify the situation.

Announcement text:

Added a section to the review guidelines indicating how to handle packages with unreviewed dependencies: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#A_note_on_dependencies

Replying to [comment:5 tibbs]:

I went ahead and added a little section to the end of the review guidelines.

Thanks

Still not sure why this was an issue at all (since, uh, the builds will fail anyway)

This is not true. For example, if rubygem- package is built without executing test suite, it can be built, without satisfied runtime dependencies. I saw packages which were built like this for 2 years and their dependencies were never satisfied.

Actually, this statement is wrong:

However, please keep in mind that you cannot do koji builds (because you cannot provide additional dependencies to koji) and when the time comes to build these packages,

Comment 7 is the first thing here which mentions runtime dependencies and I wasn't even thinking of that. I guess it would have made this whole thing far more obvious if that had been said up front. I'll fix up the page.

And I've hopefully clarified things a bit; hopefully it's better now.

Replying to [comment:9 tibbs]:

Comment 7 is the first thing here which mentions runtime dependencies and I wasn't even thinking of that.

I assumed that speaking of broken dependencies, the stuff must be already built and this implies that build dependencies are satisfied. But you are right, that this was probably obvious just to me, as a reporter. Will try better next time ;)

Thanks for clarification

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata