On Mon, February 4, 2013 19:01, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 5:36 PM, Craig White craig.white@ttiltd.com wrote:
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
I guess I still don't understand why you think that is a good thing. If the developers didn't get it right the first dozen times, why do you think the next update will be better? That is, if EPEL can't keep up, why would anyone want to? If you don't have the QA that a packager does it means you have to do it yourself.
It is a good thing in the sense that the cost of entry for developers who provide Ruby extensions is very, very, low as all platforms Ruby runs on are essentially supported out of the box by RubyGems. If one becomes expert at RPM package building on RHEL/CentOS then how exactly does that expertise translate from RHEL into say Debian; or BSD; or OSX; or MS-Windows? It does not. On the other hand, any non-native language extension released as a RubyGem and pushed to rubygems.org is instantly available on every platform running a comparable version of Ruby.
Further, with rubygems one has version control at the extension level with support for concurrent versions built in. Compare that with rpm where one has exactly one choice of a given package for the entire host.
The problem with system packagers like rpm from a Ruby developers standpoint is that frequently developers are packaging language components that are extracted from a larger application and not the application itself. This is essentially how Ruby on Rails came to be released. In such cases a system level application package management system is simultaneously too large and too small for Ruby gems. It is too big in that it requires too much overhead to get it to work at all. It is too small because it only handles one Linus distribution and does nothing at all for any non-linux OS.
One must think in terms of plugins when considering RubyGems. Firefox 10 ESR is packaged for CentOS as an rpm but most of the addons that make FF valuable to me are plugins obtained directly by FF from the Mozilla repository or from trusted third parties. These addons are not provided as rpms from RH and never will be. RubyGems serve much the same purpose as FF addons and they are implemented in a similar fashion; an extension belongs to the application and not to the system.
As for not getting 'it' right, whatever 'it' is, Ruby is not a single implementation. The baseline is the MRI but there exists several alternative implementations including one written in Java. Each of these serves a different user audience while providing a common syntax.
James B. Byrne wrote:
On Mon, February 4, 2013 19:01, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 5:36 PM, Craig White craig.white@ttiltd.com wrote:
<snip>
It is a good thing in the sense that the cost of entry for developers who provide Ruby extensions is very, very, low as all platforms Ruby runs on are essentially supported out of the box by RubyGems. If one becomes expert at RPM package building on RHEL/CentOS then how exactly does that expertise translate from RHEL into say Debian; or BSD; or OSX; or MS-Windows? It does not. On the other hand, any non-native language extension released as a RubyGem and pushed to rubygems.org is instantly available on every platform running a comparable version of Ruby.
As I keep noting, many perl CPAN packages are available as rpms - I know, since my manager prefers we not build any from CPAN unless it's a) not available from a trusted repository as an rpm, and b) actually required by a developer. As an rpm, of course, if there's an update, it'll get taken care of the next update we do; otherwise, we have to remember which of our 150 or so systems has what that has to be built. It's bad enough to have to remember which ones I have to build the NVIDIA drivers on.... <snip>
released. In such cases a system level application package management system is simultaneously too large and too small for Ruby gems. It is too big in that it requires too much overhead to get it to work at all. It is too small because it only handles one Linus distribution and does nothing at all for any non-linux OS.
Most other cross-platform projects do it. <snip>
As for not getting 'it' right, whatever 'it' is, Ruby is not a single implementation. The baseline is the MRI but there exists several alternative implementations including one written in Java. Each of
<snip> A version of ruby, a scripting language, written in Java? Please tell me which one, so I can prevent ANYONE HERE from EVER looking into that....
mark "why, yes, I *do* loathe java; ruby is merely an annoying pain"
On Tue, Feb 5, 2013 at 8:40 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
One must think in terms of plugins when considering RubyGems. Firefox 10 ESR is packaged for CentOS as an rpm but most of the addons that make FF valuable to me are plugins obtained directly by FF from the Mozilla repository or from trusted third parties.
And have you ever had problems with FF - caused by plugins? Who hasn't?
These addons are not provided as rpms from RH and never will be. RubyGems serve much the same purpose as FF addons and they are implemented in a similar fashion; an extension belongs to the application and not to the system.
Sure, but the kernel is like that too with a bazillion modules and drivers written by a whole bunch of people. And there are really, really good reasons that you don't just grab any of it straight from the developers and let it have its way with your servers - you run code that has been carefully vetted and all tested together.. Perl and CPAN is similar - if you want to devote your full time to it, you can probably keep a system running for a few years with a bunch of libraries updating directly from CPAN, but things will break randomly and you'll have to fix them yourself, where that rarely happens if you use rpms that someone else keeps in sync when the CPAN module authors refactor things.
As for not getting 'it' right, whatever 'it' is, Ruby is not a single implementation. The baseline is the MRI but there exists several alternative implementations including one written in Java. Each of these serves a different user audience while providing a common syntax.
That doesn't make it sound any more reliable - which is the real question here. What are the odds that letting a system update itself in combinations that have probably never been tested together and across platforms that aren't tested in development will keep working for any length of time. Does the gem installation process perform any testing to verify correctness? Is it transactional so an update or new install failure will back out to the previously working setup? RPM and yum aren't perfect but the thing that makes them work is the human management of the combinations of things that are added to a repository and the testing for their particular platforms. If someone is going to give up that human layer of testing and vetting, there should be some better assurance than "a lot of big sites make it work" that it is actually usable. Not everyone wants to throw a full-time admin at making a language work. And when even enthusiasts say old versions are not usable it doesn't inspire confidence.
On Tue, Feb 5, 2013 at 7:55 AM, m.roth@5-cent.us wrote:
As I keep noting, many perl CPAN packages are available as rpms - I know, since my manager prefers we not build any from CPAN unless it's a) not available from a trusted repository as an rpm, and b) actually required by a developer. As an rpm, of course, if there's an update, it'll get taken care of the next update we do; otherwise, we have to remember which of our 150 or so systems has what that has to be built.
You should check out cpanspec, available from EPEL, which makes it easy to package CPAN modules into RPMs. Well-behaved modules are nearly trivial and the Fedora Packing Guideline help make sane packages out of the more complicated modules. Then build with mock and put the RPM into a local repository and manage with yum. You might need to iterate a few time to satisfy all the dependencies, but that's a one-time deal.
The only real problem I've encountered is a program that wants to update a core perl module and RPM rightly complains about that. If had used cpan directly, I would not have been warned about the conflict and might have ended up with a broken system.
Jim
On Tue, Feb 5, 2013 at 10:22 AM, James Szinger jszinger@gmail.com wrote:
As I keep noting, many perl CPAN packages are available as rpms - I know, since my manager prefers we not build any from CPAN unless it's a) not available from a trusted repository as an rpm, and b) actually required by a developer. As an rpm, of course, if there's an update, it'll get taken care of the next update we do; otherwise, we have to remember which of our 150 or so systems has what that has to be built.
You should check out cpanspec, available from EPEL, which makes it easy to package CPAN modules into RPMs. Well-behaved modules are nearly trivial and the Fedora Packing Guideline help make sane packages out of the more complicated modules. Then build with mock and put the RPM into a local repository and manage with yum. You might need to iterate a few time to satisfy all the dependencies, but that's a one-time deal.
That keeps your rpm database happy, but it doesn't solve the real problem which is that CPAN modules can and do change in ways that make previously working combinations break. It may be rare these days, but it happens. And the value of having centrally packaged modules is that (a) the versions released together are generally tested together and (b) even if some bug slips by the release process, a lot of other people will be using the same set and can share the debugging effort and knowledge of the fix.
The only real problem I've encountered is a program that wants to update a core perl module and RPM rightly complains about that. If had used cpan directly, I would not have been warned about the conflict and might have ended up with a broken system.
That's just one of the ways things can break, though.
James Szinger wrote:
On Tue, Feb 5, 2013 at 7:55 AM, m.roth@5-cent.us wrote:
As I keep noting, many perl CPAN packages are available as rpms - I know, since my manager prefers we not build any from CPAN unless it's
a) not
available from a trusted repository as an rpm, and b) actually required by a developer. As an rpm, of course, if there's an update, it'll get
taken
care of the next update we do; otherwise, we have to remember which of our 150 or so systems has what that has to be built.
You should check out cpanspec, available from EPEL, which makes it easy to package CPAN modules into RPMs. Well-behaved modules are nearly trivial and the Fedora Packing Guideline help make sane packages out of the more complicated modules. Then build with mock and put the RPM into a local repository and manage with yum. You might need to iterate a few time to satisfy all the dependencies, but that's a one-time deal.
Why do I want to do that? I have enough systems to update, and I *try* to do it regularly, but most have unique requirements (say, the compute clusters, or the systems that the *one* project built in ruby uses). I'd much rather use yum update to deal with packages that the CentOS team, following on upstream themselves, have vetted, and have a very high probability of *not* breaking things. <snip> Of course I've used CPAN, and have done it on request, for very specific software that someone wanted, with my manager's approval, because we *don't* want to have to have a larger laundry list than we have. I like CPAN... but I like yum update better.
mark
On Tue, 5 Feb 2013 10:47:11 -0600 Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Feb 5, 2013 at 10:22 AM, James Szinger jszinger@gmail.com wrote:
You should check out cpanspec, available from EPEL, which makes it easy to package CPAN modules into RPMs. Well-behaved modules are nearly trivial and the Fedora Packing Guideline help make sane packages out of the more complicated modules. Then build with mock and put the RPM into a local repository and manage with yum. You might need to iterate a few time to satisfy all the dependencies, but that's a one-time deal.
That keeps your rpm database happy, but it doesn't solve the real problem which is that CPAN modules can and do change in ways that make previously working combinations break. It may be rare these days, but it happens. And the value of having centrally packaged modules is that (a) the versions released together are generally tested together and (b) even if some bug slips by the release process, a lot of other people will be using the same set and can share the debugging effort and knowledge of the fix.
Any program or library can break---that's why we test and verify. A proper package management system helps, but is not a panacea.
I only do this if I can't find a package from a trusted repository. I even try to rebuild the Fedora RPMs if they are available. Once I have an RPM, I can test it and then deploy to production. The spec file is record of how the package is built and mock helps protect against hidden dependecies. Having an RPM also allows for a broken package to be downgraded or removed. I have suffered enough problems from source installs and don't want to do it that way again.
The only real problem I've encountered is a program that wants to update a core perl module and RPM rightly complains about that. If had used cpan directly, I would not have been warned about the conflict and might have ended up with a broken system.
That's just one of the ways things can break, though.
It was enough to get me to drop back and punt and wait until upstream fixes their code or I can develop a patch.
Jim
-
James B. Byrne -
James Szinger -
Les Mikesell -
m.roth＠5-cent.us