Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> New Fedora and RHEL feature "Software Collections"
joka
 Posted: Jun 19 2013, 05:03 PM
Quote Post


SLF Geek
****

Group: Members
Posts: 172
Member No.: 107
Joined: 28-April 11









This week I have become aware of a new Fedora feature with name "Software Collections" that has been backported officially to EL6 and even EL5: http://jnovy.fedorapeople.org/scl-utils/scl.pdf
Or look at this article on Heise Online: http://www.h-online.com/open/news/item/Red-Hat-betas-web-developer-tool-collection-1884019.html

QUOTE
The aim of the Software Collections is to provide multiple
versions of a software in one EL installation.
The version from collection must not interact (overwrite) with system
version. Collections can provide several parallel-installable versions of
one software


The idea is not new and well known (and in some cases notorious) from proprietary packages which typically install at /opt. The news is that this idea is now supported officially by RPM (with the scl-utils).

For example, according to pkgs.org VLC is provided by 7 repos. Because of the complex dependencies (codecs) most likely all these repos are incompatible to each other. If they would provide VLC as a software collection, all its software would be installed at /opt/repo/vlc-version/x86_64/root/usr/{bin,lib64,share...} instead of /usr. VLC or other multimedia packages from different repos could then be mixed without disturbing each other - and especially without replacing* system files. So if this is working in practice, it could be the (or at least a big step to a) solution of the current EL6 "dependancy hell".

This could eliminate also the need for "backports" repositories that overwrite base packages.
Regarding my repo: I would reorganize the joka-banking repo as software collection because it currently overwrites old libraries from EPEL.

I have not yet practical experience with software collection and it may take some time to learn to handle it, but it seems to me a very interesting and promising approach. What do you think?

EDIT: *) "damaging" changed to "replacing": Changed "For example" to avoid that it could be (mis)understood as criticism of a particular repo
PM
^
tux99
 Posted: Jun 19 2013, 06:21 PM
Quote Post


SLF Moderator
********

Group: Moderators
Posts: 1273
Member No.: 224
Joined: 28-May 11









I'm not sure if you are misunderstanding the purpose of software collections or if it's me misunderstanding it, but as far as I understand it the purpose of software collections is purely to provide various versions of developer tools that can't normally be installed together like for example different versions of gcc or different versions of python or perl or other languages or of the LAMP stack.

Installing normal user apps under /opt might work for some apps, but a lot of applications make assumptions on paths and install locations (for example for plugins) therefore it would be a huge effort to build and package them all to be installed under /opt.

Also SELinux has some rules for multimedia stuff (surprisingly even for stuff that RHEL doesn't package themselves) that expect things to be in the standard locations under /usr, so these rules would need to be replaced and new rules would need to be written.

For these reasons I don't expect any of the large repos (epel, rpmforge, atrpms) to start using /opt and as I said I don't think RH intended this to happen anyway.

QUOTE
and especially without damaging system files.

If you spot any RPM from Linuxtech repos that damages system files then please let me know immediately, nothing should damage system files!
If you meant to say third party RPMs that replace base repo RPMs then that's an entirely different matter, that should be avoided as much as possible but in some limited cases it's inevitable and actually advantageous.
(although some repos like ATrpms for example replace far too many base repo RPMs even when it could be avoided)
QUOTE

This would eliminate also the need for "backports" repositories that overwrite base packages.

Actually it wouldn't because base repo RPMs expect specific stuff to be in specific locations so for example backports under /opt of libsane or hplip would simply be ignored.

--------------------
My personal SL6 repository, specialized in audio/video software: http://pkgrepo.linuxtech.net/el6/
(can be used together with EPEL and ELRepo repositories) - repository mirror: http://linuxsoft.cern.ch/linuxtech/el6/
PM
^
joka
 Posted: Jun 19 2013, 10:56 PM
Quote Post


SLF Geek
****

Group: Members
Posts: 172
Member No.: 107
Joined: 28-April 11









QUOTE (tux99 @ Jun 19 2013, 07:21 PM)

QUOTE
and especially without damaging system files.

If you spot any RPM from Linuxtech repos that damages system files then please let me know immediately, nothing should damage system files!
If you meant to say third party RPMs that replace base repo RPMs then that's an entirely different matter, that should be avoided as much as possible but in some limited cases it's inevitable and actually advantageous.
(although some repos like ATrpms for example replace far too many base repo RPMs even when it could be avoided)

Sorry, "damaging" is the wrong word here (should be "replacing"). I was thinking back to my experiences with the ATRPMs repo (after installing VLC and gstreamer plugins). The consequence of replacing system packages was that I could not upgrade from SL6.0 to 6.1. And this is what I regard as a damage of the system.

QUOTE (tux99 @ Jun 19 2013, 07:21 PM)

QUOTE
This would eliminate also the need for "backports" repositories that overwrite base packages.

Actually it wouldn't because base repo RPMs expect specific stuff to be in specific locations so for example backports under /opt of libsane or hplip would simply be ignored.

I admit, scanner and printer libraries are a good counter example.

QUOTE (tux99 @ Jun 19 2013, 07:21 PM)
Also SELinux has some rules for multimedia stuff (surprisingly even for stuff that RHEL doesn't package themselves) that expect things to be in the standard locations under /usr, so these rules would need to be replaced and new rules would need to be written.

SELinux has to be considered but shouldn't be a big problem, thanks to the "semanage -e" command: Software_Collection_SELinux_Support

QUOTE (tux99 @ Jun 19 2013, 07:21 PM)
I'm not sure if you are misunderstanding the purpose of software collections or if it's me misunderstanding it, but as far as I understand it the purpose of software collections is purely to provide various versions of developer tools that can't normally be installed together like for example different versions of gcc or different versions of python or perl or other languages or of the LAMP stack..

I don't think software collections are limited to developer tools. Perhaps it can be compared to software bundles, often found in complex MacOS application, but also in proprietary software for Linux. Depending libraries and tools are bundled and installed below one root directory.
For example, I have recently found a post in the CentOS forum how to compile GIMP 2.8 which depends on gtk-2.24 and other Gtk library upgrades. This would be a good candidate for a gimp-2.8 software collection.

But after some thougt I agree Software Collections cannot be an option for a general repository like yours, or repoforge etc. Curiosly, software collections (or in general relocatable packages installed in /opt) violate the Fedora and EPEL package guidelines. Therefore, the scl-utils are intended only for 3rd party software.

QUOTE (tux99 @ Jun 19 2013, 07:21 PM)
Installing normal user apps under /opt might work for some apps, but a lot of applications make assumptions on paths and install locations (for example for plugins) therefore it would be a huge effort to build and package them all to be installed under /opt.

I.M.H.O this is not a problem, provided pathes and install locations are relocatable relative to a root directory and the software and its plugins are part of the same collection. Otherwise the app couldn't be built by rpmbuild or within mock. However, it is a problem if the app is working together with other system tools in standard locations, e.g. if it is tightly integrated into the GNOME desktop (like gThumb :-( ).

To summarize: Software Collections seem to be an interesting method to provide upgraded software packages (in parallel to the standard versions) without replacing system packages and libraries, or to provide software that otherwise would require an update of system libraries. But sadly they are no general solution for the repository incompatibility problem.
PM
^
tux99
 Posted: Jun 20 2013, 06:45 PM
Quote Post


SLF Moderator
********

Group: Moderators
Posts: 1273
Member No.: 224
Joined: 28-May 11









QUOTE (joka @ Jun 19 2013, 11:56 PM)
The consequence of replacing system packages was that I could not upgrade from SL6.0 to 6.1. And this is what I regard as a damage of the system.

Ok I see your point but so far this hasn't been a problem with the couple of marginal packages that the linuxtech repo replaces (gstreamer-bad and libvpx). Of course the risk that this happens is much higher when a third party repo (such as ATrpms) replaces core libraries (even more so when it's not actually necessary).

QUOTE
SELinux has to be considered but shouldn't be a big problem, thanks to the "semanage -e" command: Software_Collection_SELinux_Support
Maybe not a big problem but certainly additional hassle and time.

QUOTE
I don't think software collections are limited to developer tools.

Ok it's not technically limited to developer tools but in practice given that the user has to run command line tools to switch to the software from 'software collections' (I'm not sure if that's always the case, but I saw that mentioned in the slides from your link) I don't think it's very suitable for end user desktop applications, apart from exceptional cases as mentioned below.

QUOTE
For example, I have recently found a post in the CentOS forum how to compile GIMP 2.8 which depends on gtk-2.24 and other Gtk library upgrades. This would be a good candidate for a gimp-2.8 software collection.

I agree that's a good case where packaging as a 'software collection' could make sense.

QUOTE
But after some thougt I agree Software Collections cannot be an option for a general repository like yours, or repoforge etc.

Yes, the Gimp example you gave is a nice case where it could be useful though, I'm also thinking of other apps that require GTK 2.24 or even GTK3.

Maybe at some point I will try to make such a package for EL6, not Gimp 2.8 as I don't need that, but I might eventually come across a software that I want and that would be a good case for 'software collections'.

QUOTE
Otherwise the app couldn't be built by rpmbuild or within mock.

I wasn't referring to build-time paths but to runtime paths. Of course even runtime paths could be fixed in the code but that's lots of extra work, especially if it's in multiple interdependent packages.

QUOTE
To summarize: Software Collections seem to be an interesting method to provide upgraded software packages (in parallel to the standard versions) without replacing system packages and libraries, or to provide software that otherwise would require an update of system libraries. But sadly they are no general solution for the repository incompatibility problem.


That's a perfect summary I agree with! smile.gif

--------------------
My personal SL6 repository, specialized in audio/video software: http://pkgrepo.linuxtech.net/el6/
(can be used together with EPEL and ELRepo repositories) - repository mirror: http://linuxsoft.cern.ch/linuxtech/el6/
PM
^
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll