Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
On 04/03/13 02:51 PM, Mark McLoughlin wrote: On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? Holy four month old thread revival, Batman! Why yes it does indeed mean that, since as you know, anyone in Fedora will tell you that I am _the_ person to go to for an encyclopaedic knowledge of software development, seeing as how I am the QA monkey, don't know how to write code, and don't develop any software ;) (That was a snarky way of saying, no, it doesn't mean that, it just means I was not aware of any issues like the one you describe below.) OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. Well, that sounds pretty bad. You may sign my name to the Less Of This Nonsense petition with my blessing... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
Hi, I find it sad that people are still arguing for the developer-oriented I only care about making application Y as easy to maintain on a wide variety of platforms as possible, and dismiss sysadmin security concerns as too inconvenient to follow, at the very same time one of the biggest proponents of this model, Oracle, is frantically trying to root out and eradicate all the old versions of its software due to exploitation in the wild of its security flaws. I'd think that would invalidate the approach pretty thoroughly (and to be fair Oracle inherited most of the mess from a Sun that didn't dare face developers with hard decisions. It is *no* coincidence that most problems are found in the java plugin, which was 'too hard' to open-source properly and that broke every single software project management rule in order to attract java developers). Are people still naïve enough to think shit only happens to the guy next door? When they'll have finally made every local app too unsafe to run, and forced everyone to use a daily-updated chrome, streaming apps from entities employing sysadmins that force their developers to update their deps in a timely manner, do they think their platform will still be relevant? Because this is what *I* am seeing in the market: slow pruning of entities unable to cope with modern security concerns, and hardening of you shall not take the easy developer path everywhere else. The longer you postpone security concerns the harder they are to handle, and the harder they are too handle the less competitive you get compared to others with better security hygiene. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
I'll interject my thoughts here (speaking just for myself): I think software collections are a great thing for us to provide tooling for and make easy for our users/consumers to use. That said, I don't think Fedora as a distribution should ever ship any of them. The tools/framework/etc, great. Actual collections. no. I guess I am just old, but I am pretty saddened by some of the development methodology used by some upstreams these days. The pendulum has been swinging toward bundle, release super fast, break things if we feel like it. I can only guess that this is going to bite people down the road when a widespread security issue hits a core component that lots of them bundle, or when they realize all their consumers no longer even use their newer releases (they just bundle the old ones). Anyhow, IMHO, Fedora as OS should ship one collection of integrated packages. We should try and unbundle where we can, and try and make things work, and try and educate upstreams. Just my 2 cents. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
On Mon, 2013-03-04 at 22:51 +, Mark McLoughlin wrote: (following up with more thoughts from the distutils-sig thread) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. I think this parallel installs issue is the key thing we (Fedora, OpenStack, etc.) need to help figure out. There will be incompatible updates to libraries and, like with e.g. gtk2 and gtk3, I think we'll need to support apps using different versions of the same library at the same time. Right now, Software Collections is the only way I can see that OpenStack can be packaged so we don't get screwed when an incompatible library update comes along. Nick Coghlan laid out some ideas for what could be done for Python which I summarised as: http://mail.python.org/pipermail/distutils-sig/2013-March/020082.html - the system has multiple versions of somedep installed under /usr somewhere - the latest version (2.1) is what you get if you naively just do 'import somedep' - most applications should instead somehow explicitly say they need ~1.3, -1.6 or ~-2.0 or whatever - distros would have multiple copies of the same library, but only one copy for each incompatible stream rather than one copy for each application This is a much happier prospect than either Software Collections or no support for parallel installs. It needs help to make it happen, though! Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]]
Hey, Just forwarding it here so Python folks don't miss it on the main devel list. Thanks, Mark. Forwarded Message From: Mark McLoughlin mar...@redhat.com Reply-to: Mark McLoughlin mar...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?] Date: Mon, 04 Mar 2013 22:51:31 + On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. Cheers, Mark. ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
- Original Message - On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? Python makes it a bit hard to install and use multiple parallel versions of libraries with just setuptools/distutils, so it's a bit more kosher :) Since I do both Ruby and Python packaging and I can compare them, it seems to me that the biggest difference is that Python folks aren't used to do specific version requirements (not judging what pros and cons that brings). OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. There have been similar issues with distro-packaging of Ruby applications using bundler for quite a while now [1], [2], so it's not something unseen. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. IMHO that depends how the upstreams will actually use the new functionality. It can be used both for good (better semantics of versioning making it easier for packagers to discover API changes) or bad (too tight dependencies of packages, relying on fact that users will just use venv) from Fedora's POV. Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav Slavek Kabrda. [1] http://lists.fedoraproject.org/pipermail/devel/2012-December/174912.html [2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-July/001073.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
What is the difficult on adding a file to yum.repo.d ? It is designed for that. Each initial page for an aditional repo would have instructions on how to activate it and provide a repo file to copy from. - Original Message - From: Richard W.M. Jones rjo...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 11, 2012 4:42:39 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Tue, Dec 11, 2012 at 03:18:42PM -0500, Fernando Nasser wrote: From: Richard W.M. Jones rjo...@redhat.com So let's say the user has to add the OCaml repo themselves. That's difficult for the user because lots of tools like yum search no longer work well. Really? If I add several yum repos in my tum.repo.d the yum subcommands operate over all those repos, son't they? I am surprised by this statement. Obviously I mean that yum search and many other commands don't work until and unless the user knows (how?) what repo to add. That means that you have to add the external repos for the user, or advertise them, which are incompatible as I explained. Did I overlook anything here? Lots. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Tue, Dec 11, 2012 at 07:33:13PM +, Richard W.M. Jones wrote: What I'm confused about is how this would work in terms of Fedora policy (not in terms of the software). Yes, that's important to cover too. Let's say that we decided that OCaml was non-core. It would be in a collection, and there'd be an OCaml repo, OCaml maintainer team, OCaml packaging policy and so on. I think that there are significant advantages into having these teams be under the Fedora umbrella, even if their collection is not part of core. In order to be included, collections would agree to certain rules, including an overall packaging policy. It may be that we'd have a menu of options for maintenance lifetime and etc., or we might leave that up to each SIG as long as they make it clear. If a particular group wanted to go beyond what we set as the rules for software collections in the distribution as a whole, they'd do it as an indpeendent project. Should Fedora add this repo automatically to make it easier to pull in packages? If it does that, then OCaml is really part of Fedora as far as I can see, pretty much the same as now but a bit more awkward. Maybe more awkward, but hopefully the tools could be improved so that's not the case. If it's pretty much the same but offers the advantages of decoupling the base from stack versions, that sounds great to me. What happens if the OCaml team goes rogue and starts adding non-free packages? Could Fedora be accused of contributory infringement for The same as now. If the group wants to be part of Fedora, they follow the Fedora rules. even pointing to the location of this repo? Again, if Fedora accepts detailed oversight over what goes into these external repos, then AFAICS they might as well just be in Fedora in the first place. Yes. What happens if a core program needs an OCaml program to build? Or needs to Require on one? Or (in Debian terms) could be enhanced by one? I guess this means that everything in Fedora New Core would need to be written in C and perhaps Python, and can only depend on a handful of features, and that's rather limiting for everyone. We can have system ocaml. I see this as particularly useful for, say, increased dependence on ruby-based config systems like Puppet. The system stack would be the version needed to make that work, and we wouldn't need to worry about the implications for users of the same software stack for non-system programs -- that is, developers and users building on Fedora. Same applies to Python and whatever else. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 13, 2012 at 10:06 AM, Fernando Nasser fnas...@redhat.comwrote: What is the difficult on adding a file to yum.repo.d ? It is designed for that. Each initial page for an aditional repo would have instructions on how to activate it and provide a repo file to copy from. The difficulty is that, currently, in Fedora and indeed most other modern distributions, if I want to install a piece of software, I don't want to have to Google the software, find the Fedora repository for that software, add the repo file, and then use yum to install it. I want to be able to use yum to install the software directly. Of course if this fails I'll look around on the internet for unofficial RPMs or repositories, but the point is that it's a huge inconvenience to the user to make them have to do this when, at present, they don't need to. It's not a difficulty so much as a bad or annoying design decision from an end-user standpoint. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/09/2012 03:32 PM, Michael Scherer wrote: snip Having one repo and refusing commercial software are 2 different issues. Really, they're not though. The problem is that stuff is shipped in-distro and builds deps on core packages, and those packages are revved in a symbiotic relationship with the things that need them. The two are joined at the hip in a way that third party stuff is not. If there were a forced separation between the core OS and the stuff that is installed upon it, it would benefit everything that uses the core in equal measure, not just those things shipped in the core distro today. snip And the same goes for having a stable platform, you have to make sure that the platform is well defined, so people do not start to use something outside of the platform ( or it will not work ). In fact, that's what the LSB attempted to do, yet no one ask for it in this thread. So maybe people who want a stable platform should investigate what is the status of the LSB support in Fedora, what are the needs of the ISVs, and find a plan to make them supported. I'd love LSB to matter more. But I didn't raise that can of worms intentionally :) To drill down to a single point though, as I said above, I don't want the distro to ship every piece of software I might use. Today, there is too much of a focus on doing it that way where I think there would be more value (to those who use third party software or who are pondering downstream consumers of Fedora also) in having a smaller core and treating everything that comes on top equally. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Tue, Dec 11, 2012 at 7:02 PM, Jon Masters j...@redhat.com wrote: I'd love LSB to matter more. But I didn't raise that can of worms intentionally :) To drill down to a single point though, as I said above, I don't want the distro to ship every piece of software I might use. Today, there is too much of a focus on doing it that way where I think there would be more value (to those who use third party software or who are pondering downstream consumers of Fedora also) in having a smaller core and treating everything that comes on top equally. Yeah, our how to join Fedora process makes it easiest to start by adding to the number of packages instead of by adding to the quality of existing packages. It might be beneficial to have things the other way - if someone could find a practical way to do it. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/11/2012 01:09 PM, Miloslav Trmač wrote: Yeah, our how to join Fedora process makes it easiest to start by adding to the number of packages instead of by adding to the quality of existing packages. It might be beneficial to have things the other way - if someone could find a practical way to do it If they are passionate about it, more drive by emails are hardly going to change anything. Show and tell. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Tue, Dec 11, 2012 at 01:02:41PM -0500, Jon Masters wrote: I'd love LSB to matter more. But I didn't raise that can of worms intentionally :) To drill down to a single point though, as I said above, I don't want the distro to ship every piece of software I might use. Today, there is too much of a focus on doing it that way where I think there would be more value (to those who use third party software or who are pondering downstream consumers of Fedora also) in having a smaller core and treating everything that comes on top equally. What I'm confused about is how this would work in terms of Fedora policy (not in terms of the software). Let's say that we decided that OCaml was non-core. It would be in a collection, and there'd be an OCaml repo, OCaml maintainer team, OCaml packaging policy and so on. Should Fedora add this repo automatically to make it easier to pull in packages? If it does that, then OCaml is really part of Fedora as far as I can see, pretty much the same as now but a bit more awkward. So let's say the user has to add the OCaml repo themselves. That's difficult for the user because lots of tools like yum search no longer work well. What happens if the OCaml team goes rogue and starts adding non-free packages? Could Fedora be accused of contributory infringement for even pointing to the location of this repo? Again, if Fedora accepts detailed oversight over what goes into these external repos, then AFAICS they might as well just be in Fedora in the first place. What happens if a core program needs an OCaml program to build? Or needs to Require on one? Or (in Debian terms) could be enhanced by one? I guess this means that everything in Fedora New Core would need to be written in C and perhaps Python, and can only depend on a handful of features, and that's rather limiting for everyone. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
see in line - Original Message - From: Richard W.M. Jones rjo...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 11, 2012 2:33:13 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Tue, Dec 11, 2012 at 01:02:41PM -0500, Jon Masters wrote: I'd love LSB to matter more. But I didn't raise that can of worms intentionally :) To drill down to a single point though, as I said above, I don't want the distro to ship every piece of software I might use. Today, there is too much of a focus on doing it that way where I think there would be more value (to those who use third party software or who are pondering downstream consumers of Fedora also) in having a smaller core and treating everything that comes on top equally. What I'm confused about is how this would work in terms of Fedora policy (not in terms of the software). Let's say that we decided that OCaml was non-core. It would be in a collection, and there'd be an OCaml repo, OCaml maintainer team, OCaml packaging policy and so on. Should Fedora add this repo automatically to make it easier to pull in packages? If it does that, then OCaml is really part of Fedora as far as I can see, pretty much the same as now but a bit more awkward. I don't think we can legally add it. It must be added by the user so those OCaml people go to jail, not us ;-) So let's say the user has to add the OCaml repo themselves. That's difficult for the user because lots of tools like yum search no longer work well. Really? If I add several yum repos in my tum.repo.d the yum subcommands operate over all those repos, son't they? I am surprised by this statement. What happens if the OCaml team goes rogue and starts adding non-free packages? Their repo, their problem. Could Fedora be accused of contributory infringement for even pointing to the location of this repo? Again, if Fedora accepts detailed oversight over what goes into these external repos, then AFAICS they might as well just be in Fedora in the first place. We should not even host their repo. Anything that does not undergo Fedora's strict review process must be kept segregated IMHO. disclaimer: IANAL What happens if a core program needs an OCaml program to build? Or needs to Require on one? Or (in Debian terms) could be enhanced by one? I guess this means that everything in Fedora New Core would need to be written in C and perhaps Python, and can only depend on a handful of features, and that's rather limiting for everyone. There is no problem here. Whatever we need in core we need to add in there and build in there in our own ways and it becomes part of the core and it is installed in the FHS proper places as usual. We'll have to maintain these pieces (or convince some of the OCaml guys to do it under our rules in core). The OCaml collection (or collections!!!) will have theor own copy in /opt and out of our ways. Did I overlook anything here? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Tue, Dec 11, 2012 at 03:18:42PM -0500, Fernando Nasser wrote: From: Richard W.M. Jones rjo...@redhat.com So let's say the user has to add the OCaml repo themselves. That's difficult for the user because lots of tools like yum search no longer work well. Really? If I add several yum repos in my tum.repo.d the yum subcommands operate over all those repos, son't they? I am surprised by this statement. Obviously I mean that yum search and many other commands don't work until and unless the user knows (how?) what repo to add. That means that you have to add the external repos for the user, or advertise them, which are incompatible as I explained. Did I overlook anything here? Lots. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller mat...@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_. 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. 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. 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? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
2012/12/10 Miloslav Trmač m...@volny.cz: On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller mat...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 10:38 AM, Michael Scherer wrote: People are annoyed to go to different bugzilla to report bugs, people are annoyed to go to different shops to shop for stuff ( as seen by the success of amazon, or even itunes, etc ), so why would it make sense to have a different way depending on what you want to install ? If I may, that comparison is flawed. When I shop at Amazon, I can buy the same product that I can buy at a big box store, or a smaller retailer. I'm enjoying the convenience of going to the App Store (Amazon) but I can also install the software myself (go to the local retailer), and it's all the same bits either way. It's not welded shut. Although the retailers want to screw each other out of business, competition laws require them to generally conform to the notion that I can get my bits wherever I want and install them into my home, etc. My biggest problem with the one true repo approach is that it creates this (flawed) notion that software is either right or wrong: it's either completely Open Source and shipped in the distro, or it's out there on an island. I like Open Source, I like some proprietary software too. I like some software from folks who don't care about packaging it for distros. I like some commercial software. I want my Operating System to provide a (small) stable platform that people can target. Then, by all means do an Amazon. But much as I like Apple, don't do an Apple (iOS) App Store where that's the only way to get bits, do it like they do on the desktop where there's still choice. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Le dimanche 09 décembre 2012 à 14:26 -0500, Jon Masters a écrit : On 12/06/2012 10:38 AM, Michael Scherer wrote: People are annoyed to go to different bugzilla to report bugs, people are annoyed to go to different shops to shop for stuff ( as seen by the success of amazon, or even itunes, etc ), so why would it make sense to have a different way depending on what you want to install ? If I may, that comparison is flawed. When I shop at Amazon, I can buy the same product that I can buy at a big box store, or a smaller retailer. I'm enjoying the convenience of going to the App Store (Amazon) but I can also install the software myself (go to the local retailer), and it's all the same bits either way. It's not welded shut. Although the retailers want to screw each other out of business, competition laws require them to generally conform to the notion that I can get my bits wherever I want and install them into my home, etc. Well, you can still install what you want. My point is just this is more convenient to not have different way to do the same exact thing. ( think gem vs distribution rpm, for one, this is a recipe for conflicts and problems, as they have different support lifecycle, and different features ) My biggest problem with the one true repo approach is that it creates this (flawed) notion that software is either right or wrong: it's either completely Open Source and shipped in the distro, or it's out there on an island. Having one repo and refusing commercial software are 2 different issues. Even with many repositories, you can refuse to distribute non open source softwares ( for various reasons, like this is being too much work to make contract and manage money ), and you can perfectly ship non open source software in your repository, provided you have the right to redistribute them and still have 1 single repository. I like Open Source, I like some proprietary software too. I like some software from folks who don't care about packaging it for distros. I like some commercial software. I want my Operating System to provide a (small) stable platform that people can target. Then, by all means do an Amazon. But much as I like Apple, don't do an Apple (iOS) App Store where that's the only way to get bits, do it like they do on the desktop where there's still choice. This is free software, there isn't much way to lock people into doing your way only. But that doesn't mean the project should be without rules and use the ressources for anything. If we want to ensure quality, there is a need for a common set of rules to follow to make everything work smoothly. And either you make sure the rules are followed ( by having 1 single entry point, for example ), or you do not care, and you will just end with a lower quality. Every check that is added and that can be bypassed will be bypassed sooner or later by people who do not care, do not understand, or not have the ressources. And the same goes for having a stable platform, you have to make sure that the platform is well defined, so people do not start to use something outside of the platform ( or it will not work ). In fact, that's what the LSB attempted to do, yet no one ask for it in this thread. So maybe people who want a stable platform should investigate what is the status of the LSB support in Fedora, what are the needs of the ISVs, and find a plan to make them supported. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 05:08 PM, Richard W.M. Jones wrote: On Thu, Dec 06, 2012 at 10:50:03AM -0500, Mark Bidewell wrote: I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. You're using a Mac now, so good luck. But I'm pretty sure that software collections would not have helped you to upgrade Libreoffice. Which, by the way, is possible without upgrading everything: just compile the later SRPMs. In other words, create your own backports repository, and find a group of people who have the same problem to share the security and maintenance burden around. Rich. In that case he might use gentoo ;-) On the other hand create a collection for LibreOffice and support it would be a lot of work. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Dne 6.12.2012 17:31, Seth Vidal napsal(a): On Thu, 6 Dec 2012, Jan Zelený wrote: The original use case for SCLs is to provide a way to deliver newer versions of SW in stable distributions like RHEL/CentOS than those available in the core system and make sure system packages and collection packages don't collide in any way (names, libraries, system paths, ...). right and the motivators for the above are customers/users who have to deal with their developers complaining about wanting a specific/newer/older/intermediate version of some language or another and its modules. they complain to their ops people, they complain to fedora/red hat. Oh common. You offended every developer on this ML. May be you should consider that it is not just about developers, but it is also about their management and customers who pays their bills. In my previous job, we were developing application for our internal customer. During development, we were free to use any library which suited our needs. However, in some point, our customer was satisfied with functionality he had and he didn't want to spent any more money on development. Since that time, during maintenance, it was not any more my choice what library of what version I will use, since the system was built and running. Now suddenly, after several years, the provider wants to quit their services and the application needs to be migrated. That would be perfect case for SC, because it would allow migration with lowest cost. So what you would suggest? Was there any decision wrong in that process? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Fernando Nasser fnas...@redhat.com a écrit: And _maintain_ them, with all security fixes. The problem with duplication is above all one of scalability of maintenance. Please, avoiding top-posting like this would be very welcome here. Otherwise, it is quite hard to know what you are replying to exactly. Thank you for your understanding. -- Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, December 7, 2012 11:54:46 AM Subject: Re: What would it take to make Software Collections work in Fedora? Dne 6.12.2012 17:31, Seth Vidal napsal(a): On Thu, 6 Dec 2012, Jan Zelený wrote: The original use case for SCLs is to provide a way to deliver newer versions of SW in stable distributions like RHEL/CentOS than those available in the core system and make sure system packages and collection packages don't collide in any way (names, libraries, system paths, ...). right and the motivators for the above are customers/users who have to deal with their developers complaining about wanting a specific/newer/older/intermediate version of some language or another and its modules. they complain to their ops people, they complain to fedora/red hat. Oh common. You offended every developer on this ML. May be you should consider that it is not just about developers, but it is also about their management and customers who pays their bills. In my previous job, we were developing application for our internal customer. During development, we were free to use any library which suited our needs. However, in some point, our customer was satisfied with functionality he had and he didn't want to spent any more money on development. Since that time, during maintenance, it was not any more my choice what library of what version I will use, since the system was built and running. Now suddenly, after several years, the provider wants to quit their services and the application needs to be migrated. That would be perfect case for SC, because it would allow migration with lowest cost. So what you would suggest? Was there any decision wrong in that process? Migration time is the perfect time to modernize your application. And the customer will pay the bill no matter what - whether he will pay for the creation of the SC or for modernizing the application. Why would you pay for maintaining some obsolete system when you can make it work in a more supportable way? This sounds really wrong to me. If we speak about people that are fine paying certain amount for maintaining SC every couple of months until it becomes impossible to maintain the app and they pay even more to write new app I would say that your definition of lowest cost is quite short sided. Alexander Kurtakov Red Hat Eclipse team Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 07:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! So what if we actually do .. but in a different way - eg. we would ensure that we have stable API, no feature breakage in a release for a package that do belong to core and allow faster turnaround for packages in extras .. it's not like locking it down as it used to be but defining more strict rules for certain set of packages. R -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal rvo...@redhat.com wrote: On 12/06/2012 07:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! So what if we actually do .. but in a different way - eg. we would ensure that we have stable API, no feature breakage in a release for a package that do belong to core and allow faster turnaround for packages in extras .. it's not like locking it down as it used to be but defining more strict rules for certain set of packages. R -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel +1 -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal rvo...@redhat.com wrote: On 12/06/2012 07:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! So what if we actually do .. but in a different way - eg. we would ensure that we have stable API, no feature breakage in a release for a package that do belong to core and allow faster turnaround for packages in extras .. it's not like locking it down as it used to be but defining more strict rules for certain set of packages. Doesn't this describe the critpath[1] process? Rich [1] https://fedoraproject.org/wiki/Critical_path_package -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 6, 2012 at 6:39 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 5.12.2012 22:14, Kevin Fenzi napsal(a): I cant seem to find any specific fpc ticket where they discussed this, but I am pretty sure it was brought up before there. I'd check with them... https://fedorahosted.org/fpc/ticket/141 https://fedorahosted.org/fpc/ticket/143 But I am afraid not everything written there :/ Vít https://fedorahosted.org/fpc/ticket/115 original blocker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 5, 2012 at 4:04 PM, Matthew Miller mat...@fedoraproject.org wrote: 3) It's the ecosystem. If using Software Collections on RHEL is good for your company, it's good for it to work on Fedora, because a) we're the upstream and problems get worked out here, b) development resources benefit Fedora rather than being spent in a pocket universe, and c) Software Collections which work across the whole ecosystem in a consistent way make us a stronger choice for development work which may eventually end up on Enterprise Linux in production. To echo on the ecosystem comment. There are things inside, on top, alongside or under a distribution. Fedora takes the view that everything inside should be consistent without redundancy. This is extremely useful and important. But Fedora does not have a policy for the other elements - what should be on top, how should it be on top for example. A while back Fedora started the ISV SIG and Greg had a beautiful blog post [1] on why that initiative failed. It failed because the communication to the ISVs was that they should be inside Fedora and what they wanted to be is on top of Fedora. Software Collections is hope of creating a distinction between the distribution and all that it contains, and an ability for 3rd parties to to create their own world on top. This always brings back the question of what is Fedora - folks think I am making snide remarks when I use that phrase - but the question in implicit in some of the discussion in this thread. 1 - Fedora is the linux software distribution 2 - Fedora is the community infrastructure that enables a linux distribution and an ecosystem. The two statements are quite different in their impact. [1] http://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 01:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 10:40 AM, Jon Masters j...@redhat.com wrote: On 12/06/2012 01:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel +1 Personally I think the line should be drawn similar to FreeBSD/Ports. Core should be primarily OS kernel, shell utilities and C compiler. Maybe X as well. Extras should be anything not required for an operational system even if installed by the initial install. My biggest beef with Linux packaging has been that, by and large, all packages have to be upgraded in sync if you want to have a supported system. Battle for Wesnoth shouldn't be tied to kernel updates. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 07, 2012 at 02:08:28AM -0500, Bohuslav Kabrda wrote: I don't think I fully understand your question here. Every SCL is confined in its own root under /opt/.../name/root. So you can either do two SCLs, ^^^ Or wherever we decide is the appropriate place -- I think this was one of the sticking points before. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 07, 2012 at 10:40:13AM -0500, Jon Masters wrote: We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe The bad idea was the insider-vs-outsider mentality inherent in the way the split was made. I don't think anyone wants to go back to that, and, the above joke aside, I think it's clear that we wouldn't draw the line in the same way, and we would *definitely* have different rules than in those days. To a lot of people who weren't so close to all that, the name Fedora Core still has good connotations -- I still often meet people who refer to Fedora as that. I don't know what the balance in the community now is of people who have that kind of rosy-eyed fondness, people who are new and don't have a history either way, and people who remember the Dark Times and would be put off by the name. they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. I think we *could* have both. There's no reason that Fedora couldn't make that stable core platform *and* provide layers above it. In fact, referring to https://fedoraproject.org/wiki/Overview?rd=FedoraProject:About#Our_Mission it seems pretty clear that both levels are in scope. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 07, 2012 at 10:54:46AM +0100, Vít Ondruch wrote: In my previous job, we were developing application for our internal customer. During development, we were free to use any library which suited our needs. However, in some point, our customer was satisfied with functionality he had and he didn't want to spent any more money on development. Since that time, during maintenance, it was not any more my choice what library of what version I will use, since the system was built and running. Now suddenly, after several years, the provider wants to quit their services and the application needs to be migrated. That would be perfect case for SC, because it would allow migration with lowest cost. So what you would suggest? Was there any decision wrong in that process? I think the real lesson is that platforms should take backwards compatibility more seriously. The single best decision that libvirt has ever made was to promise to support the libvirt API and ABI forever. If you wrote a program against libvirt 0.0.1 (or whatever it was) 7 years ago, it should still work today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 7, 2012 at 12:49 PM, Richard W.M. Jones rjo...@redhat.com wrote: I think the real lesson is that platforms should take backwards compatibility more seriously. The single best decision that libvirt has ever made was to promise to support the libvirt API and ABI forever. If you wrote a program against libvirt 0.0.1 (or whatever it was) 7 years ago, it should still work today. Easier said than done in some cases -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Fri, Dec 07, 2012 at 05:49:24PM +, Richard W.M. Jones wrote: I think the real lesson is that platforms should take backwards compatibility more seriously. The single best decision that libvirt has ever made was to promise to support the libvirt API and ABI forever. If you wrote a program against libvirt 0.0.1 (or whatever it was) 7 years ago, it should still work today. And that's awesome, and *we* can do that when we make code. And we can even ask nicely for other people to follow the same practices. But, it's a wild world out there. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Marcela Mašláňová (mmasl...@redhat.com) said: You're using a Mac now, so good luck. But I'm pretty sure that software collections would not have helped you to upgrade Libreoffice. Which, by the way, is possible without upgrading everything: just compile the later SRPMs. In other words, create your own backports repository, and find a group of people who have the same problem to share the security and maintenance burden around. Rich. In that case he might use gentoo ;-) On the other hand create a collection for LibreOffice and support it would be a lot of work. I would suspect, actually, that upgrading to a later LibreOffice is fairly simple on a 'stable' release, if it was built for that release. The problem comes when the only newer LibreOffice is built for the next Fedora release, so it's linked against newer libicu/boost/clucene/etc/etc that's only available in that later Fedora release, even though it doesn't specifically *require* those newer library versions. Of course, just doing an update for an older release breaks those who want the older release to maintain stability at all costs. So the LibreOffice case could be fixed by merely defining what's inside the always-stable set vs. what's outside it and can be updated more frequently (and convincing the maintainer to do so with LibreOffice.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/07/2012 12:30 PM, Matthew Miller wrote: On Fri, Dec 07, 2012 at 10:40:13AM -0500, Jon Masters wrote: We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe The bad idea was the insider-vs-outsider mentality inherent in the way the split was made. I don't think anyone wants to go back to that, and, the above joke aside, I think it's clear that we wouldn't draw the line in the same way, and we would *definitely* have different rules than in those days. Sure. Slight caveat that I do prefer Enterprise-leaning inspiration everything ;) but I don't want a return to inside-vs-outside either. To a lot of people who weren't so close to all that, the name Fedora Core still has good connotations -- I still often meet people who refer to Fedora as that. I don't know what the balance in the community now is of people who have that kind of rosy-eyed fondness, people who are new and don't have a history either way, and people who remember the Dark Times and would be put off by the name. Hey, it's still fc18 (for various RPM versioning reasons) :) they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. I think we *could* have both. There's no reason that Fedora couldn't make that stable core platform *and* provide layers above it. In fact, referring to https://fedoraproject.org/wiki/Overview?rd=FedoraProject:About#Our_Mission it seems pretty clear that both levels are in scope. Sure we could. There's nothing to prevent a company or an organization from shipping an OS as well as software that installs upon it. Plenty do. But it's when one gets in the business of shoving in the kitchen sink and believing that everything must be provided in the one true repo that the problem comes. I want to be able to get packaged third party software for distros like Fedora more easily. If there's an expectation that some kind of platform compatibility has to exist, we might even see that happen. I was encouraged last night that the latest Altera design tools work on Fedora 17 with only one compat library being installed, but I've been far less lucky with other stuff. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Dne 5.12.2012 22:14, Kevin Fenzi napsal(a): I cant seem to find any specific fpc ticket where they discussed this, but I am pretty sure it was brought up before there. I'd check with them... https://fedorahosted.org/fpc/ticket/141 https://fedorahosted.org/fpc/ticket/143 But I am afraid not everything written there :/ Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 2012-12-06 at 02:57 -0500, Bohuslav Kabrda wrote: Packaging two parallel versions of interpreters brings not only the burden of maintaining them, but also the work to make them not conflict. E.g. renaming binaries, checking shebangs all the time, etc. With SCLs, this is much simpler and more transparent (my POV). I don't think Fedora's Ruby-SIG is going to do that. Are you simply saying that you're not going to care for the issue making 2 SCL that depends on different version of Ruby simply not installable in parallel ? Or are you saying that the SCL will be confined in its own 'root' so they will not conflict ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. I think those people only like software collections as long as they are not held accountable about the (security…) state those collections are in, either because someone else bears the burden of maintaining them (typical case in a software shop where a sysadmin got tasked with collecting the bits developers code against, and then gets forbidden to update them to avoid some work for those developers), or because no one is looking closely at the sorry state the software collections are left in. The long term effect of software collections is to make whatever is built on them irrelevant, as the more you procrastinate about updating, the more work it is to update, till updating becomes totally out-of-the-question and everyone accepts your product is going to the toilet with the bricks it has been built on the day they finally irredeemably break. IE kleenex programming (Oracle has perfected this strategy: their J2EE products quality is often abysmal, but they only need to survive long enough to rack in the money needed to buy a better competitor the day those products find no new buyers). Do we really want to go this way at the Fedora level? Our angle was more to enable a sustainable software ecosystem, that didn't need regular cash infusions to replace applications that became irrelevant due to lack of maintenance. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
2012/12/5 Matthew Miller mat...@fedoraproject.org: There is a perpetual problem facing all Linux distributions around how fast to move with software updates. In Fedora, of course, our default speed is petal-to-the-metal. This is part of who we are and why we are awesome. However, it also sometimes makes life difficult for us -- for example, our Puppet packages are broken because Ruby is too new. It also makes life difficult for people trying to use Fedora seriously. It's especially hard with Ruby and Java -- not that there's anything _wrong_ with these languages, but the packaging expectations are different and often in conflict with the system operator's traditional packaging worldview. Somewhat of an example of a very complex package tied to a large amount of other packages that needs custom patches or specific versions is sagemath http://fedoraproject.org/wiki/SIGs/SciTech/SAGE Sagemath has what it calls spkgs, see for example http://sagemath.org/download-packages.html and the upstream distribution of sagemath is a base directory anywhere, and inside it a tree with its own python, a huge collection of packages, even its own gcc. I did package sagemath in Mandriva for several years, and am now working on getting it in Fedora. My package works with system packages, but there are a few exceptions due to either sagemath being tied to something too old, having some really intrusive patch that upstream does not accept, or a too fast moving target that is too hard to keep updating/remaking non trivial patches that still may break badly because some package in the distro was updated. The solution I used for these in Mandriva and hoping to get approved for Fedora is bundling. For now it is 3 non trivial packages, that are ipython, cython and pexpect. Everything else I managed to get to work with the distro version. With some time, *and* with sagemath integrated in the distro it should also make upstream pay more attention and coordinate better in the different projects, and those bundled components eventually may not need to be required anymore. Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Le mercredi 05 décembre 2012 à 22:25 -0600, Michael Ekstrand a écrit : On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). People are annoyed to go to different bugzilla to report bugs, people are annoyed to go to different shops to shop for stuff ( as seen by the success of amazon, or even itunes, etc ), so why would it make sense to have a different way depending on what you want to install ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.comwrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 06, 2012 at 03:30:32PM +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. I think those people only like software collections as long as they are not held accountable about the (security…) state those collections are in, either because someone else bears the burden of maintaining them (typical case in a software shop where a sysadmin got tasked with collecting the bits developers code against, and then gets forbidden to update them to avoid some work for those developers), or because no one is looking closely at the sorry state the software collections are left in. The long term effect of software collections is to make whatever is built on them irrelevant, as the more you procrastinate about updating, the more work it is to update, till updating becomes totally out-of-the-question and everyone accepts your product is going to the toilet with the bricks it has been built on the day they finally irredeemably break. IE kleenex programming (Oracle has perfected this strategy: their J2EE products quality is often abysmal, but they only need to survive long enough to rack in the money needed to buy a better competitor the day those products find no new buyers). Do we really want to go this way at the Fedora level? Our angle was more to enable a sustainable software ecosystem, that didn't need regular cash infusions to replace applications that became irrelevant due to lack of maintenance. I agree completely. It seems to me the software collections stuff is all about RHEL, and almost nothing to do with Fedora (what important platform comes out more often than once every 6 months???) If Puppet and Rails can't be installed in Fedora, that's because Puppet and Rails are buggy and/or their upstream processes are broken, and we should work with upstream on fixing their bugs or their processes. Upstream first, right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - From: Nicolas Mailhot nicolas.mail...@laposte.net To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 4:30:32 PM Subject: Re: What would it take to make Software Collections work in Fedora? IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. I think those people only like software collections as long as they are not held accountable about the (security…) state those collections are in, either because someone else bears the burden of maintaining them (typical case in a software shop where a sysadmin got tasked with collecting the bits developers code against, and then gets forbidden to update them to avoid some work for those developers), or because no one is looking closely at the sorry state the software collections are left in. The long term effect of software collections is to make whatever is built on them irrelevant, as the more you procrastinate about updating, the more work it is to update, till updating becomes totally out-of-the-question and everyone accepts your product is going to the toilet with the bricks it has been built on the day they finally irredeemably break. IE kleenex programming (Oracle has perfected this strategy: their J2EE products quality is often abysmal, but they only need to survive long enough to rack in the money needed to buy a better competitor the day those products find no new buyers). Do we really want to go this way at the Fedora level? Our angle was more to enable a sustainable software ecosystem, that didn't need regular cash infusions to replace applications that became irrelevant due to lack of maintenance. I couldn't have said it better. :) Alexander Kurtakov Red Hat Eclipse team -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 06, 2012 at 10:50:03AM -0500, Mark Bidewell wrote: I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. You're using a Mac now, so good luck. But I'm pretty sure that software collections would not have helped you to upgrade Libreoffice. Which, by the way, is possible without upgrading everything: just compile the later SRPMs. In other words, create your own backports repository, and find a group of people who have the same problem to share the security and maintenance burden around. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 6. 12. 2012 at 10:50:03, Mark Bidewell wrote: On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.comwrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. Well, not exactly, you would still need to upgrade all packages that the new version of Libreoffice depends on and all packages these updated packages depend on and so on ... The only difference is that these updated packages would need to be a part of the collection while keeping the rest of the system intact. However the maintenance burden would be even higher, as maintainers would need to take care of multiple versions of packages in each Fedora. Bottom line, the final effect for user wouldn't be much different from current state of things (in fact it might get even more complicated by the non-trivial way how programs in collections are executed). Therefore this isn't exactly the use case SCLs try solve. -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - From: Adam Williamson awill...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 5:06:04 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. As someone familiar with the Java ecosystem (at least a bit :) I would disagree with you Adam. Our opinion starts to matter and we are starting to make changes aka upstreams are willing to accept our changes and the process is accelerating. It would be very sad if we gave up now. We have big influence over the Eclipse ecosystem, we start to have influence over the Java buildsystems, and etc. P.S. Small clarification needed - when I say Java I mean things that run on top of the JVM BUT Java EE. Even I lost hope on that part. Alexander Kurtakov Red Hat Eclipse team -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: Well, not exactly, you would still need to upgrade all packages that the new version of Libreoffice depends on and all packages these updated packages depend on and so on ... The only difference is that these updated packages would need to be a part of the collection while keeping the rest of the system intact. However the maintenance burden would be even higher, as maintainers would need to take care of multiple versions of packages in each Fedora. Bottom line, the final effect for user wouldn't be much different from current state of things (in fact it might get even more complicated by the non-trivial way how programs in collections are executed). Therefore this isn't exactly the use case SCLs try solve. I find it interesting that we've not really named the use case that SCLs are trying to solve for. It appears to be for the case of a developer who wants to run against a specific version of something (normally a language or module for that language) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - From: Mark Bidewell mbide...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 5:50:03 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca : adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. So are you saying that you will do the scl enabled builds of libraries needed by LibreOffice ? Alexander Kurtakov Red Hat Eclipse team -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 6. 12. 2012 at 11:08:43, Seth Vidal wrote: On Thu, 6 Dec 2012, Jan Zelený wrote: Well, not exactly, you would still need to upgrade all packages that the new version of Libreoffice depends on and all packages these updated packages depend on and so on ... The only difference is that these updated packages would need to be a part of the collection while keeping the rest of the system intact. However the maintenance burden would be even higher, as maintainers would need to take care of multiple versions of packages in each Fedora. Bottom line, the final effect for user wouldn't be much different from current state of things (in fact it might get even more complicated by the non-trivial way how programs in collections are executed). Therefore this isn't exactly the use case SCLs try solve. I find it interesting that we've not really named the use case that SCLs are trying to solve for. It appears to be for the case of a developer who wants to run against a specific version of something (normally a language or module for that language) The original use case for SCLs is to provide a way to deliver newer versions of SW in stable distributions like RHEL/CentOS than those available in the core system and make sure system packages and collection packages don't collide in any way (names, libraries, system paths, ...). However as sort of a side effect all other use cases emerge (more stable SW in Fedora, multiple versions of SW, ...). -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: The original use case for SCLs is to provide a way to deliver newer versions of SW in stable distributions like RHEL/CentOS than those available in the core system and make sure system packages and collection packages don't collide in any way (names, libraries, system paths, ...). right and the motivators for the above are customers/users who have to deal with their developers complaining about wanting a specific/newer/older/intermediate version of some language or another and its modules. they complain to their ops people, they complain to fedora/red hat. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Quoting Adam Williamson (2012-12-06 16:06:04) On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. Actually, most of current Java ecosystem is sane when Maven is being used. We can automate Maven into oblivion. We are short time from making Maven packages be as simple as: ... %build %mvn_build %install %mvn_install ... As a bonus, Maven in principle discourages bundling because it's trivial to add new dependencies properly so that's making stuff easier for us overall. There are issues with the ecosystem, but they have been mostly caused by CLASSPATH handling in JVM. This will hopefully go away with new JVMs, but I won't hold my breath for it (but there is some traction there so who knows). What I am most afraid of is (in descending order): 1. Too much focus on backward compat (a lot of upstreams are still trying to support JVM 1.4) 2. Constant reinventing of wheel (tens of XML libraries still being used) 3. Going backwards - gradle build system which takes worst things from ant, and scons and combines them in one ugly package I am quite optimistic though, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
And _maintain_ them, with all security fixes. The problem with duplication is above all one of scalability of maintenance. - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 11:14:01 AM Subject: Re: What would it take to make Software Collections work in Fedora? - Original Message - From: Mark Bidewell mbide...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 5:50:03 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca : adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. So are you saying that you will do the scl enabled builds of libraries needed by LibreOffice ? Alexander Kurtakov Red Hat Eclipse team -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Note that two versions of a product that is already being maintained anyway could be a candidate, but of course this is something _for_ the OS, not part of it (RHEL, not Fedora in the exemple I have in mind). - Original Message - From: Fernando Nasser fnas...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 11:44:27 AM Subject: Re: What would it take to make Software Collections work in Fedora? And _maintain_ them, with all security fixes. The problem with duplication is above all one of scalability of maintenance. - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 11:14:01 AM Subject: Re: What would it take to make Software Collections work in Fedora? - Original Message - From: Mark Bidewell mbide...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, December 6, 2012 5:50:03 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca : adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. So are you saying that you will do the scl enabled builds of libraries needed by LibreOffice ? Alexander Kurtakov Red Hat Eclipse team -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 6, 2012 at 10:50 AM, Mark Bidewell mbide...@gmail.com wrote: I used to use Fedora as my primary OS (Now I use a Mac). The major issue which drove me away and which I believe SC would help to solve is that with the current dependency model is that it becomes I want a new version of Libreoffice so now I have to upgrade my entire system from the Kernel on up (and by upgrade I mean clean install) to avoid issues. SC would help decouple system and userland apps which would do wonders for usability. While this is fine and dandy, it's not really a problem that Software Collections was written to solve. In a nutshell, Software Collections are primarily used for development software stacks -- imagine being able to run Perl 5.10, 5.12, and 5.14 all on the same box, or PHP 5.2 and 5.3 and 5.4, or similar for Python, Ruby, Java, etc. It was never intended to be a run any version of any application with another other version of system tools type solution. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
So the point of view on SC matters. If you live the EL/EPEL world and have some Fedora, SC make a lot of sense. If you only use Fedora, Fedora moves fast enough to likely not have a ton of use for them. I think that's been hit. As for Puppet, I've proposed several ideas on how to improve Puppet on Fedora/EPEL and basically it turned into a bitch-fest. I'm still working a plan on it. When a distro chooses First as one of their foundations, that comes with problems. Fedora is the first (and only of the 8 major Linux distros we support) to only have Ruby 1.9 support. We have a puppet that fully supports Ruby 1.9. It didn't make it into Fedora 17. I've been working hard to see if it's possible for F18. I could get into more discussion on Puppet with EPEL/Fedora, but that's been covered. Back to software collections: I'm in favor for EL. On Fedora, meh. In fact some of CentOS people have already spoken with Puppet Labs about maybe doing something with SCs for EL if needed. (Obvious disclaimer, I work at Puppet Labs) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - On Thu, 2012-12-06 at 02:57 -0500, Bohuslav Kabrda wrote: Packaging two parallel versions of interpreters brings not only the burden of maintaining them, but also the work to make them not conflict. E.g. renaming binaries, checking shebangs all the time, etc. With SCLs, this is much simpler and more transparent (my POV). I don't think Fedora's Ruby-SIG is going to do that. Are you simply saying that you're not going to care for the issue making 2 SCL that depends on different version of Ruby simply not installable in parallel ? Or are you saying that the SCL will be confined in its own 'root' so they will not conflict ? I don't think I fully understand your question here. Every SCL is confined in its own root under /opt/.../name/root. So you can either do two SCLs, each with different Ruby version; one SCL with version different then what's in the system; or place both versions into the system, where I see the significant maintenance burden. The last option is the only currently possible in Fedora, but Ruby-SIG is not going to do that. Does that answer it? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - From: Matthew Miller mat...@fedoraproject.org To: Fedora Development List devel@lists.fedoraproject.org Sent: Wednesday, December 5, 2012 6:17:56 PM Subject: What would it take to make Software Collections work in Fedora? There is a perpetual problem facing all Linux distributions around how fast to move with software updates. In Fedora, of course, our default speed is petal-to-the-metal. This is part of who we are and why we are awesome. However, it also sometimes makes life difficult for us -- for example, our Puppet packages are broken because Ruby is too new. It also makes life difficult for people trying to use Fedora seriously. It's especially hard with Ruby and Java -- not that there's anything _wrong_ with these languages, but the packaging expectations are different and often in conflict with the system operator's traditional packaging worldview. As a Java guy I'm more and more sure that the problem is not in the packaging view but in the wrong view of developers not being capable of making an application if they don't bundle everything. You're write the problem is not in the languages it's in the developers :(. Alexander Kurtakov Red Hat Eclipse team So, some Red Hat folks have developed an idea called Software Collections http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html which is aimed at this problem -- it lets you install and choose between different versions of RPM-packaged software in parallel at run-time. The base tool for enabling this (scl-utils) is included in Fedora, but we don't allow Software Collections actually as Fedora packages (see https://fedoraproject.org/wiki/SoftwareCollections). This is for very good reasons -- there are a number of huge unanswered questions around structure, infrastructure, maintenance, and security updates. 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, b) develop a medium-term plan for solving those problems, and c) develop a longer-term plan for taking full advantage of the functionality where appropriate. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 5, 2012 at 11:17 AM, Matthew Miller mat...@fedoraproject.org wrote: So, some Red Hat folks have developed an idea called Software Collections http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html which is aimed at this problem -- it lets you install and choose between different versions of RPM-packaged software in parallel at run-time. Given the short shelf-life of a Fedora release and the complication involved in Software Collections, I'm still not convinced that we really need this in Fedora. Can you give me a concrete case where Fedora really needs to be running two different versions of the same software, in a production environment? Given it's longer shelf life and different target audience, RHEL is a better candidate -- and the record, the company I work for uses Software Collections that way. I'm just having a hard time justifying it in my mind for Fedora. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 05, 2012 at 02:40:15PM -0500, Jared K. Smith wrote: Given the short shelf-life of a Fedora release and the complication involved in Software Collections, I'm still not convinced that we really need this in Fedora. Can you give me a concrete case where Fedora really needs to be running two different versions of the same software, in a production environment? Given it's longer shelf life and different target audience, RHEL is a better candidate -- and the record, the company I work for uses Software Collections that way. I'm just having a hard time justifying it in my mind for Fedora. Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. 2) On a long-lived platform, Software Collections can provide a way to move faster than the base. On a fast-moving platform like Fedora, we could use it in the other way: providing longer-lived versions of certain components even as the base is upgraded. 3) It's the ecosystem. If using Software Collections on RHEL is good for your company, it's good for it to work on Fedora, because a) we're the upstream and problems get worked out here, b) development resources benefit Fedora rather than being spent in a pocket universe, and c) Software Collections which work across the whole ecosystem in a consistent way make us a stronger choice for development work which may eventually end up on Enterprise Linux in production. Obviously all of these areas (particularly #2) have significant policy, infrastructure, and resource needs to work out. Maybe they're such that it's not worth it, we can't do it, or we find a better way to accomplish the same goals. But either way, that's why I'm bringing this up. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 05, 2012 at 04:06:38PM -0500, Bill Nottingham wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical I have a cautious leaning in favor of this heresy. (*Looks around for angry villagers with torches*.) It seems like (eventually) the Software Collections mechanism might provide part of the infrastructure for doing that cleanly. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 5 Dec 2012 16:04:16 -0500 Matthew Miller mat...@fedoraproject.org wrote: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. I think this tells us more about puppet than Fedora actually. ;( ...snip... I think your first step is finding out the items that made the FPC disallow use of software collections in Fedora and work to solve those. I know they had concerns about FHS / pathing... I cant seem to find any specific fpc ticket where they discussed this, but I am pretty sure it was brought up before there. I'd check with them... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/05/2012 04:04 PM, Matthew Miller wrote: 2) On a long-lived platform, Software Collections can provide a way to move faster than the base. On a fast-moving platform like Fedora, we could use it in the other way: providing longer-lived versions of certain components even as the base is upgraded. That is a noble goal---it would be nice if it implied a long-term support commitment, but I understand that the Fedora Project does not have resources to support software older than the usual N-2. People who value stability over agressive development would still get some benefit from your proposal, but I think they would be better served by a true long-term support distribution (RHEL, Centos, Scientific, or (horrors!) Debian LTS) Ceterum censeo, it would be nice if there was a smooth migration path off Fedora into one of these LTS setups, for those that can't upgrade for one reason or another. I know it's hard and/or impossible, but I just had to say again that it'd be useful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, Dec 5, 2012 at 4:14 PM, Kevin Fenzi ke...@scrye.com wrote: I think this tells us more about puppet than Fedora actually. ;( I couldn't have said it better than this myself. The biggest reason people are really pushing for software collections (at least from what little I've seen them discussed publicly) is that particular programs only work with specific versions of an application stack. I don't know much about Ruby, but it seems to be the prime target here -- Puppet only wants to run on one version, and Rails only wants to run on another.I would argue that this is much more indicative of a potential problem in the Ruby ecosystem, not of a potential problem in Fedora. Now again, I don't know much about Ruby, and maybe I'm missing something key here. I'm willing to be enlightened if I am. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5 December 2012 14:50, Jared K. Smith jsm...@fedoraproject.org wrote: On Wed, Dec 5, 2012 at 4:14 PM, Kevin Fenzi ke...@scrye.com wrote: I think this tells us more about puppet than Fedora actually. ;( I couldn't have said it better than this myself. The biggest reason people are really pushing for software collections (at least from what little I've seen them discussed publicly) is that particular programs only work with specific versions of an application stack. I don't know much about Ruby, but it seems to be the prime target here -- Puppet only wants to run on one version, and Rails only wants to run on another.I would argue that this is much more indicative of a potential problem in the Ruby ecosystem, not of a potential problem in Fedora. Now again, I don't know much about Ruby, and maybe I'm missing something key here. I'm willing to be enlightened if I am. I think from the OS side of view, it is a problem with the various stacks.. from the application developer trying to get it done, it is a problem with the OS. In the gray center of systems administration... it is a problem with both. I am going with nottings heretical view. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 2012-12-05 at 16:10 -0500, Matthew Miller wrote: On Wed, Dec 05, 2012 at 04:06:38PM -0500, Bill Nottingham wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical I have a cautious leaning in favor of this heresy. (*Looks around for angry villagers with torches*.) It seems like (eventually) the Software Collections mechanism might provide part of the infrastructure for doing that cleanly. Isn't the risk that things will get more broken in collections, due to dependencies not being anymore strictly checked in a single repository and general disconnection between the 'main' repo and the specific collection ? Imo the concept of collection can only work against a relatively stable core, a fast changing core calls for often broken packages. Unless you want to start keeping around multiple versions of a package so that collections can have strong dependencies on specific package versions in the core. By keeping multiple versions of a package in the repo you allow collections to always be installable even if they are built against not the very latest package version and the core has since moved on. As soon as the collection is rebuilt against the newer version then dps will be resolved and all the packages will update. The only drawback is that a collection may end up blocking upgrades for security issues, not sure how to handle that, but if you do not have a stable core you either have a single gigantic repo so all dependencies can be verified or you accept multiple rpms in the repo and the fact some deps my hold back security updates. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5 December 2012 15:07, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 16:10 -0500, Matthew Miller wrote: On Wed, Dec 05, 2012 at 04:06:38PM -0500, Bill Nottingham wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical I have a cautious leaning in favor of this heresy. (*Looks around for angry villagers with torches*.) It seems like (eventually) the Software Collections mechanism might provide part of the infrastructure for doing that cleanly. Isn't the risk that things will get more broken in collections, due to dependencies not being anymore strictly checked in a single repository and general disconnection between the 'main' repo and the specific collection ? I would expect any sort of Software Collections would be a large Installer Beware item where Fedora does not guarantee anything (it works, it will have security fixes, it doesn't break other stuff) and it is between the Installer and the SC group that made the bundle to deal with those issues. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 2012-12-05 at 15:14 -0700, Stephen John Smoogen wrote: On 5 December 2012 15:07, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 16:10 -0500, Matthew Miller wrote: On Wed, Dec 05, 2012 at 04:06:38PM -0500, Bill Nottingham wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical I have a cautious leaning in favor of this heresy. (*Looks around for angry villagers with torches*.) It seems like (eventually) the Software Collections mechanism might provide part of the infrastructure for doing that cleanly. Isn't the risk that things will get more broken in collections, due to dependencies not being anymore strictly checked in a single repository and general disconnection between the 'main' repo and the specific collection ? I would expect any sort of Software Collections would be a large Installer Beware item where Fedora does not guarantee anything (it works, it will have security fixes, it doesn't break other stuff) and it is between the Installer and the SC group that made the bundle to deal with those issues. You still need to keep multiple versions of RPMs in the core repo. Otherwise Collections may simply not be installable from scratch at all if any of their package depends strictly on a slightly older version than the bleeding edge. Incidentally keeping multiple version would also allow more graceful downgrades when needed, instead of forcing people to go to koji to download the older version because it disappeared from repos. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5 December 2012 15:35, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 15:14 -0700, Stephen John Smoogen wrote: On 5 December 2012 15:07, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 16:10 -0500, Matthew Miller wrote: On Wed, Dec 05, 2012 at 04:06:38PM -0500, Bill Nottingham wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical I have a cautious leaning in favor of this heresy. (*Looks around for angry villagers with torches*.) It seems like (eventually) the Software Collections mechanism might provide part of the infrastructure for doing that cleanly. Isn't the risk that things will get more broken in collections, due to dependencies not being anymore strictly checked in a single repository and general disconnection between the 'main' repo and the specific collection ? I would expect any sort of Software Collections would be a large Installer Beware item where Fedora does not guarantee anything (it works, it will have security fixes, it doesn't break other stuff) and it is between the Installer and the SC group that made the bundle to deal with those issues. You still need to keep multiple versions of RPMs in the core repo. Would that not cause a combinatoric nightmare with having to make sure you had a libX11 compiled against say X number of glibc's or other libraries that changed in the past so that you had the correct path so that SC KDE-4.9 had the correct combination it wants of core stuff and SC GNOME-3.9 had the correct combination for it? What I have seen with similar commercial software collections you just replicate everything you need to make your stack work all the way down to libc if needed. It is stupid in that case but it will trend towards that as more versions are required to be supported. In the end the OS is mainly meant to be a firstboot to get the software collections installed and working. Otherwise Collections may simply not be installable from scratch at all if any of their package depends strictly on a slightly older version than the bleeding edge. Incidentally keeping multiple version would also allow more graceful downgrades when needed, instead of forcing people to go to koji to download the older version because it disappeared from repos. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 2012-12-05 at 15:47 -0700, Stephen John Smoogen wrote: Would that not cause a combinatoric nightmare with having to make sure you had a libX11 compiled against say X number of glibc's or other libraries that changed in the past so that you had the correct path so that SC KDE-4.9 had the correct combination it wants of core stuff and SC GNOME-3.9 had the correct combination for it? No you always build against the latest. But the older rpms are useful if one collection package has Requires: foobar = 1.2.3 If then core releases foobar 1.2.4 (which is perfectly ABI compatible and all and wouldn;t really cause issues blah blah blahg) and 1.2.3 is not also left in the repo the collection becomes uninstallable. Of course some people may claim that's a mistake, but the point of collections is indeed to not have to drink from the firehose so for some packages it would probably make sense to have a strict dependency so you know the collection works if installed because that specific critical package has been tested and it is know to work. We recently introduced a similar package for freeipa that you can optionally install and locks down dependencies tightly. This way people that do not want to risk suffering from breackage if one component updates before we have tested all the pieces can install said package and nothing it requires is updated until we test all the stuff and update it with new version requires. This is still experimental but I can clearly see how it would be logical for some collections to work that way. The main issue with that package is lack of 'older' package versions in the repos, which means if you install freeipa 'late' then you cannot lock it down because you can;t find the exact version that is 'known to work'. It would be really nice to be able to do this in Fedora land. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5 December 2012 15:56, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 15:47 -0700, Stephen John Smoogen wrote: Would that not cause a combinatoric nightmare with having to make sure you had a libX11 compiled against say X number of glibc's or other libraries that changed in the past so that you had the correct path so that SC KDE-4.9 had the correct combination it wants of core stuff and SC GNOME-3.9 had the correct combination for it? No you always build against the latest. But the older rpms are useful if one collection package has Requires: foobar = 1.2.3 If then core releases foobar 1.2.4 (which is perfectly ABI compatible and all and wouldn;t really cause issues blah blah blahg) and 1.2.3 is not also left in the repo the collection becomes uninstallable. What if 1.2.3 had to be upgraded to 1.2.4 because it was a security issue or some similar item. At that point the system can be locked down but not fixed. So either 1.2.3 would need a backported fix or the SC would need to carry its own fixed version. Or am I missing something? -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/05/2012 04:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical That would be *epicly* *awesome* in so many ways, and it'll never happen. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 2012-12-05 at 16:09 -0700, Stephen John Smoogen wrote: On 5 December 2012 15:56, Simo Sorce s...@redhat.com wrote: On Wed, 2012-12-05 at 15:47 -0700, Stephen John Smoogen wrote: Would that not cause a combinatoric nightmare with having to make sure you had a libX11 compiled against say X number of glibc's or other libraries that changed in the past so that you had the correct path so that SC KDE-4.9 had the correct combination it wants of core stuff and SC GNOME-3.9 had the correct combination for it? No you always build against the latest. But the older rpms are useful if one collection package has Requires: foobar = 1.2.3 If then core releases foobar 1.2.4 (which is perfectly ABI compatible and all and wouldn;t really cause issues blah blah blahg) and 1.2.3 is not also left in the repo the collection becomes uninstallable. What if 1.2.3 had to be upgraded to 1.2.4 because it was a security issue or some similar item. At that point the system can be locked down but not fixed. So either 1.2.3 would need a backported fix or the SC would need to carry its own fixed version. Or am I missing something? You pressure the SC to rebuild against 1.2.4 in Fedora, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Hi On Wed, Dec 5, 2012 at 4:04 PM, Matthew Miller wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. While I can see why it might be useful to SC overall, why isn't packaging two different versions of Ruby an option for this specific case? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. I wouldn't at all mind even seeing multiple packaging systems at work - RPM manages the core system, and something like PC-BSD's PBIs used for “applications”. But it does seem unlikely to ever happen, at least in the context of an existing distribution. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5. 12. 2012 at 11:17:56, Matthew Miller wrote: There is a perpetual problem facing all Linux distributions around how fast to move with software updates. In Fedora, of course, our default speed is petal-to-the-metal. This is part of who we are and why we are awesome. However, it also sometimes makes life difficult for us -- for example, our Puppet packages are broken because Ruby is too new. It also makes life difficult for people trying to use Fedora seriously. It's especially hard with Ruby and Java -- not that there's anything _wrong_ with these languages, but the packaging expectations are different and often in conflict with the system operator's traditional packaging worldview. So, some Red Hat folks have developed an idea called Software Collections http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/ Software_Collections_Guide/index.html which is aimed at this problem -- it lets you install and choose between different versions of RPM-packaged software in parallel at run-time. The base tool for enabling this (scl-utils) is included in Fedora, but we don't allow Software Collections actually as Fedora packages (see https://fedoraproject.org/wiki/SoftwareCollections). This is for very good reasons -- there are a number of huge unanswered questions around structure, infrastructure, maintenance, and security updates. 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, b) develop a medium-term plan for solving those problems, and c) develop a longer-term plan for taking full advantage of the functionality where appropriate. Hi, I guess the main reason why SCL is not used in Fedora it requires a certain (potentially non-trivial) amount of work from package maintainer. However feel free to make your packages SCL enabled. You shouldn't have any issues with that. Just make necessary modification in your spec files, build all packages against the Fedora in which you want them and host them in your repo. The only inconvenience here is that Fedora infrastructure isn't yet prepared for simple support of private repositories in a style of Launchpad so you have to do all this work manually. If you have any questions, I'll be more than happy to answer them if I can. -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 5. 12. 2012 at 16:50:03, Jared K. Smith wrote: On Wed, Dec 5, 2012 at 4:14 PM, Kevin Fenzi ke...@scrye.com wrote: I think this tells us more about puppet than Fedora actually. ;( I couldn't have said it better than this myself. The biggest reason people are really pushing for software collections (at least from what little I've seen them discussed publicly) is that particular programs only work with specific versions of an application stack. I don't know much about Ruby, but it seems to be the prime target here -- Puppet only wants to run on one version, and Rails only wants to run on another.I would argue that this is much more indicative of a potential problem in the Ruby ecosystem, not of a potential problem in Fedora. Now again, I don't know much about Ruby, and maybe I'm missing something key here. I'm willing to be enlightened if I am. -- Jared Smith Well, that might be just one of the reasons why we developed SCL. However another reason is to provide different version of software than the one that is a part of base system. For Fedora you might want to use more stable software for your production environment. OTOH for a stable distribution like RHEL, you might want to do the exact opposite - have more up-to-date software than the stable one in your distribution. It also gives you the option to create your own private package stack parallel to the one on the system and have the possibility to let them coexist. Of course this applies to the case when you for some reason (e.g. an evil patch or something) don't want your version of the software in the Fedora. -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: Hi, I guess the main reason why SCL is not used in Fedora it requires a certain (potentially non-trivial) amount of work from package maintainer. However feel free to make your packages SCL enabled. You shouldn't have any issues with that. Just make necessary modification in your spec files, build all packages against the Fedora in which you want them and host them in your repo. The only inconvenience here is that Fedora infrastructure isn't yet prepared for simple support of private repositories in a style of Launchpad so you have to do all this work manually. Bohuslav and I are working hard on making the copr code ready. http://git.fedorahosted.org/cgit/copr.git and very soon we're going to need more help. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
- Original Message - Hi On Wed, Dec 5, 2012 at 4:04 PM, Matthew Miller wrote: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. While I can see why it might be useful to SC overall, why isn't packaging two different versions of Ruby an option for this specific case? Rahul Packaging two parallel versions of interpreters brings not only the burden of maintaining them, but also the work to make them not conflict. E.g. renaming binaries, checking shebangs all the time, etc. With SCLs, this is much simpler and more transparent (my POV). I don't think Fedora's Ruby-SIG is going to do that. General Ruby vs. SCLs comments (explained for non-Rubyists, too :) ): In Ruby world (yes, Ruby is probably the first that comes to mind when talking about SCLs), SCLs make great sense. Considering a standard Rails application, say Redmine [1], it is custom of the upstreams to lock these applications with certain versions of Gems. This is done using Bundler [2] (it doesn't really bundle libraries, but locks the dependency set) via Gemfile, resp. Gemfile.lock. Gemfile specifies general dependencies, while on installation of these dependencies, Gemfile.lock is produced that lists the specific versions of the installed dependencies (and their dependencies etc.). This is great for developers, as they can just pull the app from git and install precisely the same set of dependencies as the other people who were developing (or deploy it with the same set of deps, too). It is of course not so great for packagers, as the upstreams say these are the versions that we support now and we can never know whether Redmine will work with the versions we have in Fedora (yes, you can run unittests, but you can never be 100% sure). But let's say that Redmine works with versions we have in Fedora and we package it, creating Gemfile.lock for the package. But what happens when we update a dependency of Redmine (judging from its Gemfile, I'd say it'll give more than 100 Gems)? So when updating any of these packages, we have to retest and rebuild Redmine (to regenerate its Gemfile.lock). We can probably do this while having one application like this, but it starts to be unmanageable with just couple more similar applications. And you can't solve this problem by having multiple versions of Ruby, you'd end up having tons of multiple versions of Gems, too. (This starts to be nice with the whole append version to name, so that the packages don't conflict RPM solution.) This issue of packaging applications with Gemfiles into Fedora is periodically being discussed on Fedora's Ruby-SIG, so far with no real outcomes. Please note, that the Ruby community is sometimes very aggressive to distro packagers, saying that distro packaging of Gems is useless etc. Generally, the world of YUM/RPM and world of Bundler/Gem are just very divergent by their nature and don't play that well together, as other packaging ecosystems do (it seems to me that Python community is 100 % more packager friendly than Ruby). Now back to SCLs. Considering Redmine, you can build the whole stack of its dependencies in SCL, while not polluting the system Gems with hybrid rubygem-foo23 versions. Rather, you create, say, redminescl-rubygem-foo package in the version Redmine needs. Not only it tells you right away where it belongs by its name, it also means you are free to do whatever with it's versions, because you are detached from Fedora. So if someone comes and says hey, I want to package this Ruby/Rails/whatever app for Fedora, you just tell him to do the collection and maintain it. Now I'm not 100 % sure we should allow anyone to create any SCL in Fedora, but it would certainly make sense for some cases. Generally, SCLs solve these problems: having multiple parallel versions of libraries (or better say stacks) and more importantly detaching the application's lifecycle from Fedora's and including everything specific that this application needs (specific versions, etc.). -- Regards, Bohuslav Slavek Kabrda. [1] http://www.redmine.org/ [2] http://gembundler.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
