Language specific mirrors for Fedora Playground compliant packages

[Vít Ondruch]

Hi Nick

Dne 15.9.2014 10:19, Nick Coghlan napsal(a):
> As mentioned in my self-introduction email, I'm interested in the idea
> of filtered Fedora provided mirrors of PyPI/RubyGems/etc that contained
> only packages that had been through Fedora Playground levels of review.
>
> Having such selective mirrors available would mean that we could freely
> choose between using the language level packaging tools and RPMs on a
> project by project basis without having to recheck the licenses
> ourselves. It would also provide a way for us to easily share the
> results of our own licensing reviews when we bring in new dependencies
> from upstream.

While you plot this nicely and it sounds attractive, I am really against
this idea. Here are a few points which comes to my mind:

1) Speaking of Rubyists, you would need to convince them to start using
"source "https://fedora-rubygems-mirror.org" instead of standard "source
"https://rubygems.org"" in their Gemfiles. Not sure how you would like
to achieve this. We could patch Bundler somehow to substitute the
original source on Fedora, but I don't want to imagine what source of
problems it would bring.

2) In Fedora, there are packages, which are modified from upstream
versions. For example, rubygem-listen [1] provides universal API to
provide notifications about file changes on file system. Upstream
decided, that they will have hard dependencies on other platform
specific libraries, which supports FS level notifications. We decided to
drop them, since it does not make sense to support libraries which does
nothing on Linux. Sometimes, we are forced to override overly tight
dependencies on other libraries. And now to the question. What would
happened with such gem? What the mirror should provide in such case?
Fedora's version or upstream version of gem? The former is quite
dangerous idea, since it would end up in two different packages of the
same version.

3) You need additional human/infrastructure resources.

Additionally to the point 3, if you have such resources, I would be
better to invest them into development of proper support of multiple
versions of packages in DNF. That would remove the need for most of the
SCLs and additional repositories in Copr, at least speaking of Ruby
ecosystem.

Nowadays, people are not using ruby193 collection, because they are in
love with Ruby 1.9.3. They are using the collection since it is bundled
with Ruby on Rails 3.2. And they are using SCLs just because it allows
them to install more versions of RoR on single system, not because they
believe that their worflow is now much easier. But you can achieve it
just fine with rpm -i having the RPMs. It is just not supported by
DNF/YUM, since DNF/YUM understands just "upgrade, don't leave old
version on system".


Vít


[1] http://rubygems.org/gems/listen