Broken dependencies in F21

Vít Ondruch vondruch at
Thu Oct 16 13:04:22 UTC 2014

Thanks for bringing this up. Speaking of broken Ruby stuff:

	rubygem-linecache19-0.5.13-6.fc20.armv7hl requires

	rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires

A while ago, I suggested to drop these and rubygem-ruby-debug19 as well,
but the question is still unanswered by maintainer:

	rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) < 0:3.2.0

This seems to be abandoned by upstream:

	rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(activemodel) < 0:4.1
	rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(actionpack) < 0:4.1

I guess we are waiting for new upstream release here.

	deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers)
	deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles)

Not sure how active is the upstream, but I asked maintainer/deltacloud
upstream and he seems to go to orphan this package. But the fix might be
as easy as dropping the dependencies, since they were retired in Fedora.

	ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
	rubygem-thinking-sphinx-3.1.0-2.fc21.noarch requires rubygem(joiner) >= 0:0.2.0

Not sure about the state of these two. It seems they were broken by
updated dependencies, so they should be either updated, the dependencies
should be relaxed (but also in .gemspec file, so it would need some
patching) or fixed if there are some incompatibilities.


Dne 16.10.2014 v 14:40 Kalev Lember napsal(a):
> Hi all,
> We seem to have a number of broken dependencies in F21 that have gone
> unfixed for a quite some time. Not sure what's up with them; the
> maintainers are supposed to get daily notifications to make sure these
> don't go unnoticed.
> Does anyone have ideas how to deal with these packages?
> I wonder if it would make sense to just drop them before F21. Having
> broken dependencies basically means that the packages are completely
> broken and cannot be installed at all. Not much point in shipping those
> in the repositories ...
> Any ideas how to deal with this?

More information about the devel mailing list