What would it take to make Software Collections work in Fedora?

[Paulo César Pereira de Andrade]

2012/12/10 Miloslav Trmač <mitr at volny.cz>:
> On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller <mattdm at fedoraproject.org> wrote:
>> I think, though, that this tool, integrated well and supported, could really
>> help us in Fedora (and in EPEL). So, I'd like to
>>
>> a) enumerate the problems with Software Collections in Fedora,
>
> Nicolas's mail has covered the "single package" point of view
> perfectly - relying on software collections/frozen versions typically
> indicates the package is slowly dying, or based on a problematic
> technology.
>
> Let me add another view:
>
> From the point of view of a distribution, relying on software
> collections/frozen versions indicates _it is failing its purpose as a
> distribution_.

  Another issue is that usually not only does software depend on
a frozen version number, it frequently also depends on it patched.

  But these usually are software too complex that the authors
cannot cope with the speed of abi/api changes. Usually the core
software is in some interpreted language, usually python, it
usually will also have compiled .so modules that break easily,
the interpreted language itself may change in subtle ways, and
due to interpreted, frequently carry bugs that will only manifest
at runtime when some code path is exercised.

> The purpose of a distribution is to integrate various upstream pieces
> of software into a coherent whole.  That means file system layout
> standards, naming standards, infrastructure standards, etc., but the
> absolute minimum is the ability to run a piece of software included in
> the distribution in the first place.

  Getting back to my sample/anecdotal sagemath package
https://bugzilla.redhat.com/show_bug.cgi?id=877651 waiting for
some brave soul to review it for almost a month now (I made the
review request when I thought it was in an acceptable shape),
I had it working and have been updating it for roughly six months
now, and was working for almost a year to get it working in
fedora; significant amount of patches being added to different
packages, several new packages, adding workarounds to
the sagemath package because upstream would not agree
with sagemath patches, etc. Well, upstream (in this case
sagemath) cannot handle it if supporting different distros, building
for old distributions or different operating systems, they will just
bundle most of the software they need.

> It quite often is a distribution, and in particular, _our_
> distribution, where somebody first seriously tries to use software
> package against an updated dependency.  In such a situation, the
> package maintainers in the distribution should initiate and actively
> work on integrating the two, collaborating with the respective
> upstreams, not just give up and wish for software collections.

  There is another package I would love to build in Fedora, but I do
not know if I will be able to (because there is also significant legal
stuff to evaluate)... That is http://www.salome-platform.org/
I made all components/dependencies work in Mandriva for a few
years, but last time I touched it I had some probably simple
python/qt4 breakage and it is broken since then
https://qa.mandriva.com/show_bug.cgi?id=65396
I was also having significant trouble with the swig and doxygen
versions, and lately a lot of problems with the paraview interface
(that I had disabled because I would need to bundle it, I spent
quite some time trying to patch it because at that time v3.10
and v3.11 were quite different internally...)

> If we as Fedora give up on integrating the software that comes from
> upstreams, what good do we do for our users?  Where is our added
> value?

  I gave two examples of fully open source software. But there are
those "closed source" software around, like some that distribute
only .pyc/.pyo files, or some different approach to "hide" the
sources...

>     Mirek

Paulo