2012/12/10 Miloslav Trmač <mitr(a)volny.cz>:
On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller
<mattdm(a)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