2012/12/10 Miloslav Trmač <mitr@xxxxxxxx>: > On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
