There are significant components of the upstream 5.6 release which are stuck behind the CentOS 5.6 release process, but are now incorporated in EPEL 5 components. In particular, the "php53" package is now necessary for the "drupal6" EPEL components, due to the long out of date PHP 5.1 in the default upstream vendor's codebase.
I see that some of these components are available in the "testing" repository at http://dev.centos.org/centos/5/CentOS-Testing.repo. But this isn't published with centos-release. fasttrack is. Would it be reasonable to push these "testing" components over to "fasttrack"? Given our "upstream vendor's" policy of making all the updates available to all the previous releases in their main "channels", I'm not sure there's any reason not to present them, at least to the fasttrack" channel, and migrate them from "fasttrack" to "updates" as necessary.
Other components for such fasttrack publication might include bind97, which some CentOS users have been asking for.
On 20/03/11 15:23, Nico Kadel-Garcia wrote:
There are significant components of the upstream 5.6 release which are stuck behind the CentOS 5.6 release process, but are now incorporated in EPEL 5 components. In particular, the "php53" package is now necessary for the "drupal6" EPEL components, due to the long out of date PHP 5.1 in the default upstream vendor's codebase.
I see that some of these components are available in the "testing" repository at http://dev.centos.org/centos/5/CentOS-Testing.repo. But this isn't published with centos-release. fasttrack is. Would it be reasonable to push these "testing" components over to "fasttrack"? Given our "upstream vendor's" policy of making all the updates available to all the previous releases in their main "channels", I'm not sure there's any reason not to present them, at least to the fasttrack" channel, and migrate them from "fasttrack" to "updates" as necessary.
Other components for such fasttrack publication might include bind97, which some CentOS users have been asking for.
We've had this discussion before - the fasttrack repository is a rebuild of the upstream FasTrack channel, nothing more. Except it's never actually been populated for CentOS-5.
The correct place for these packages is in os/5.6 when released. In the meantime they have been publicly released to testing for those who want early access (fasttrack access if you prefer) or who want to test and provide feedback.
Incompatibilities between EPEL and CentOS caused due to the delay in releasing 5.6 are a matter for EPEL to resolve. CentOS are doing their best to resolve the issue their end by getting 5.6 out as fast as possible.
On Sun, 20 Mar 2011, Nico Kadel-Garcia wrote:
There are significant components of the upstream 5.6 release which are stuck behind the CentOS 5.6 release process, but are now incorporated in EPEL 5 components.
Sad that -- that the dependent partial Red Hat adjunct project is not compatible with people not using Red Hat's product
The unpleasantness of reading continual criticism, from those who will not do the minimal local rebuilds, to use the packages from a project not affiliated with the CentOS project, has pretty effectively driven the CentOS core developers away from this mailing list
Congratulations
Niko, I notice you did out post your 'helpful criticism' to which I respond, on the EPEL list on how to do the workaround EPEL's policies of not shipping packages competing with Red Hat's enterprise product. Perhaps they would welcome it (probably not, as they consciously DO NOT COMPETE with the parent product)
CentOS has an ethic of delivering a product with certain quality expectations and testing before it is released (rather than inflicting a partially baked release and then streaming out curative fixes)
If a person doesn't like CentOS's pace and attention to shipping durable and 'correct' releases or with different features (as with EPEL), or want packages faster than CentOS' rate, PLEASE encourage them to either learn to show some minimal self-reliance in building, or to not use CentOS as a base
my $ 0.02
-- Russ herrold
The unpleasantness of reading continual criticism, from those who will not do the minimal local rebuilds, to use the packages from a project not affiliated with the CentOS project, has pretty effectively driven the CentOS core developers away from this mailing list
...
If a person doesn't like CentOS's pace and attention to shipping durable and 'correct' releases or with different features (as with EPEL), or want packages faster than CentOS' rate, PLEASE encourage them to either learn to show some minimal self-reliance in building, or to not use CentOS as a base
http://www.usatoday.com/money/smallbusiness/columnist/abrams/2011-03-18-how-...
On Sun, 20 Mar 2011, Александр Кириллов wrote:
http://www.usatoday.com/money/smallbusiness/columnist/abrams/2011-03-18-how-...
CentOS has no clients to whom a contractual duty of support is owed. If SLAs, sales engineers, 800 numbers, and such are wanted or needed, PLEASE buy a contract from someone
TANSTAAFL
I have a blog series in preparation of a generalized nature, on doing spot rebuilds of packages in a one-off per package build chroot. Shall I make it freely available on my bloc, which the CentOS Planet, put it behund a paywall, or sell it in print form at Lulu? Entirely my decision as I alone have done the work and hold the copyright
I appreciate the thoughtfulness behind a one line URL post pointing out that I am wrong and to be berated
-- Russ herrold
http://www.usatoday.com/money/smallbusiness/columnist/abrams/2011-03-18-how-...
CentOS has no clients to whom a contractual duty of support is owed. If SLAs, sales engineers, 800 numbers, and such are wanted or needed, PLEASE buy a contract from someone
TANSTAAFL
The point is it's probably as easy to lose a "community" if this still matters to the core CentOS team. After so many suggestions to look elsewhere instead of providing minimal feedback for those still interested the long overdue "free lunch" would probably stuck down the throat. And yes I started looking elsewhere and with reasonably priced offer from Oracle this project is probably dead in the water.
Best regards, AK
On Mar 20, 2011, at 10:30 AM, Александр Кириллов wrote:
http://www.usatoday.com/money/smallbusiness/columnist/abrams/2011-03-18-how-...
CentOS has no clients to whom a contractual duty of support is owed. If SLAs, sales engineers, 800 numbers, and such are wanted or needed, PLEASE buy a contract from someone
TANSTAAFL
And yes I started looking elsewhere and with reasonably priced offer from Oracle this project is probably dead in the water.
Hi AK,
Why would you swing so radically in the other direction from free to fee?
Have you looked at SL? They don't have 5.6 but seem to be on a stable 6.0 rel.
- aurf
CentOS has no clients to whom a contractual duty of support is owed. If SLAs, sales engineers, 800 numbers, and such are wanted or needed, PLEASE buy a contract from someone
TANSTAAFL
And yes I started looking elsewhere and with reasonably priced offer from Oracle this project is probably dead in the water.
Hi AK,
Why would you swing so radically in the other direction from free to fee?
Have you looked at SL? They don't have 5.6 but seem to be on a stable 6.0 rel.
Hi,
I'm not actually looking for free. I'd gladly support the efforts of our "prominent North American Enterprise Linux vendor" with what little I have if their offers wouldn't be so ridiculously expensive. I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free. I didn't get into details yet but this sounds like a viable alternative.
AK
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
-- Eero
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
On 3/20/2011 3:30 PM, Les Mikesell wrote:
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
exactly. Nothing against Centos but I've deployed my last RH based box. It'll be either Debian or Ubuntu from now on.
On Mar 20, 2011, at 1:52 PM, William Warren wrote:
On 3/20/2011 3:30 PM, Les Mikesell wrote:
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
exactly. Nothing against Centos but I've deployed my last RH based box. It'll be either Debian or Ubuntu from now on.
I don't get it, why so radical?
Why not go SL and maintain the same methodology?
- aurf
On 3/20/2011 6:02 PM, aurfalien@gmail.com wrote:
On Mar 20, 2011, at 1:52 PM, William Warren wrote:
On 3/20/2011 3:30 PM, Les Mikesell wrote:
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
exactly. Nothing against Centos but I've deployed my last RH based box. It'll be either Debian or Ubuntu from now on.
I don't get it, why so radical?
Why not go SL and maintain the same methodology?
- aurf
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
because the software i use for myself and my clients...rhel availability is dropping and unbuntu debian is increasing. rhel's various code decisions aren't helping. It's not radical..it's still Linux and still free.
It'll be either Debian or Ubuntu from now on.
Ubuntu makes a great server. But because of recent news I tried opensuse for the first time and I really like it.
I understand the need for stability, but for what I do, having the newest (stable) kernel and packages has a greater benefit.
Kernel 2.6.37 is in some releases now, and although everyone is crazy about 2.6.38, I'll wait until its released as an official upgrade.
And that won't be long - just a few months, likely...
On Mar 20, 2011, at 4:00 PM, compdoc wrote:
It'll be either Debian or Ubuntu from now on.
Ubuntu makes a great server. But because of recent news I tried opensuse for the first time and I really like it.
Yes, PVOPS and over all better Xen tools is a great reason to use OpenSuse.
However, having a distro like Centos is great because it is RHEL minus the support offerings.
- aurf
On 3/20/2011 7:00 PM, compdoc wrote:
It'll be either Debian or Ubuntu from now on.
Ubuntu makes a great server. But because of recent news I tried opensuse for the first time and I really like it.
I understand the need for stability, but for what I do, having the newest (stable) kernel and packages has a greater benefit.
Kernel 2.6.37 is in some releases now, and although everyone is crazy about 2.6.38, I'll wait until its released as an official upgrade.
And that won't be long - just a few months, likely...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
to which news are you referring about ubuntu-wise?
On 3/20/2011 7:11 PM, compdoc wrote:
to which news are you referring about ubuntu-wise?
I meant recent redhat news about the change in how it will deliver code to the community. They mentioned opensuse as being a competitor, I believe.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
On 3/20/2011 7:29 PM, compdoc wrote:
their changes are really aimed at oracle..the rest is smoke and
Somehow a story led me to try opensuse. Sorry, don't know which it was that I read.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
oh they mentioned opensuse as part of the kernel patch obfuscation issue that was raised..that's probably where opensuse got your attention..but their mention of opensuse is jsut to hide the fact their latest thing is aimed at oracle..:)
On 3/20/11 6:59 PM, William Warren wrote:
oh they mentioned opensuse as part of the kernel patch obfuscation issue that was raised..that's probably where opensuse got your attention..but their mention of opensuse is jsut to hide the fact their latest thing is aimed at oracle..:)
If you are going to pretend you aren't selling software, just the support service, you can't at the same time complain about what others do with that software. It was enough of a farce when they just restricted redistribution of their binaries.
On Sun, March 20, 2011 7:29 pm, William Warren wrote:
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Marko
On 3/20/2011 10:44 PM, Marko A. Jennings wrote:
On Sun, March 20, 2011 7:29 pm, William Warren wrote:
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Marko _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
nods i forgot about that mention in same said article..:)
On Sun, 20 Mar 2011, Marko A. Jennings wrote:
On Sun, March 20, 2011 7:29 pm, William Warren wrote:
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
On Mon, March 21, 2011 5:51 am, Dag Wieers wrote:
On Sun, 20 Mar 2011, Marko A. Jennings wrote:
On Sun, March 20, 2011 7:29 pm, William Warren wrote:
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
As far as I understand (I don't have first-hand knowledge of this aspect of their offering), Novell is providing their own updates.
Here is the link to their web page that advertises 30 day free support for RHEL: http://www.novell.com/promo/suse/free-30days-expanded-support.html
Marko
On Mon, March 21, 2011 5:51 am, Dag Wieers wrote:
On Sun, 20 Mar 2011, Marko A. Jennings wrote:
On Sun, March 20, 2011 7:29 pm, William Warren wrote:
their changes are really aimed at oracle..the rest is smoke and mirrors..:) oracle is basically(pardon me here) Centos with charges. That's basically all oracle is going with unbreakable Linux.
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
As far as I understand (I don't have first-hand knowledge of this aspect of their offering), Novell is providing their own updates.
Here is the link to their web page that advertises 30 day free support for RHEL: http://www.novell.com/promo/suse/free-30days-expanded-support.html
As the faq states (http://www.novell.com/products/expandedsupport/faq.html) Novell simply rebuilds the RHEL source rpms and sells them to RedHat customers.
So, it's like CentOS, but only with updates, no full distribution, no installer, but you can pay for it :)
Simon
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
On Mon, Mar 21, 2011 at 10:34 AM, compdoc compdoc@hotrodpc.com wrote:
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
Did you read the SUSE page?!
They are offering to support the RHEL install(s) not to replace RHEL by SUSE, just like Oracle.
On Mon, Mar 21, 2011 at 10:34 AM, compdoc compdoc@hotrodpc.com wrote:
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
Did you read the SUSE page?!
They are offering to support the RHEL install(s) not to replace RHEL by SUSE, just like Oracle.
Did we read the same page? When you buy Novell (SUSE) support for RedHat EL, you will still run your original RedHat EL installation but then update packages rebuilt by Novell. Technically that's the same like adding the CentOS repo config to your RedHat installation and then install all updates from CentOS instead of RedHat. What a mess, why would anyone in the world want this? And then pay $ for the mess...
Simon
Did we read the same page? When you buy Novell (SUSE) support for RedHat EL, you will still run your original RedHat EL installation but then update packages rebuilt by Novell. Technically that's the same like adding the CentOS repo config to your RedHat installation and then install all updates from CentOS instead of RedHat. What a mess, why would anyone in the world want this? And then pay $ for the mess...
Most likely because of relative cost and/or perceived value of SLES vs RHEL?
Novell is essentially offering to help you while you switch existing kit over to SLES. If you're already paying for a RHEL subscription, Novell's offer may have a lower cost or offer better value then RHEL
On Mon, 21 Mar 2011, Drew wrote:
Most likely because of relative cost and/or perceived value of SLES vs RHEL?
Novell is essentially offering to help you while you switch existing kit over to SLES. If you're already paying for a RHEL subscription, Novell's offer may have a lower cost or offer better value then RHEL
Please, folks -- These are just not CentOS issues -- and the commercial player chess-games and interplay not even vaguely related to the subject matter which started this thread.
Please take this elsewhere
Thank you
-- Russ herrold
Please, folks -- These are just not CentOS issues -- and the commercial player chess-games and interplay not even vaguely related to the subject matter which started this thread.
Please take this elsewhere
Sorry, you're right.
On Mon, Mar 21, 2011 at 12:13 PM, Drew drew.kay@gmail.com wrote:
Did we read the same page? When you buy Novell (SUSE) support for RedHat EL, you will still run your original RedHat EL installation but then update packages rebuilt by Novell. Technically that's the same like adding the CentOS repo config to your RedHat installation and then install all updates from CentOS instead of RedHat. What a mess, why would anyone in the world want this? And then pay $ for the mess...
Most likely because of relative cost and/or perceived value of SLES vs RHEL?
Novell is essentially offering to help you while you switch existing kit over to SLES. If you're already paying for a RHEL subscription, Novell's offer may have a lower cost or offer better value then RHEL
From experience with previous SuSE releases, it's also a really bad
move. Has anyone else worked with SuSE the last few years and attest whether they've addressed the joke that is their setup tool (YaST), the insistence on only one kernel, or the mish-mosh of installing their authorized non-RPM bundled NVidia or other drivers? I'd urge someone considering both to jump to our favorite upstream vendor *immediately* for commercial support, and migrate exactly the *other* way. There were some preferences in Europe for KDE, which is why I wound up working with SuSE, but the compatibility of Gnome and KDE has matured to where one can reasonable select either on CentOS and our favorite upstream vendor's enterprise linux. And for that money, you actually get feature requests accomplished and the authors of the technology to help fix bugs.
On Mon, Mar 21, 2011 at 12:00 PM, Simon Matter simon.matter@invoca.ch wrote:
On Mon, Mar 21, 2011 at 10:34 AM, compdoc compdoc@hotrodpc.com wrote:
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
Did you read the SUSE page?!
They are offering to support the RHEL install(s) not to replace RHEL by SUSE, just like Oracle.
Did we read the same page? When you buy Novell (SUSE) support for RedHat EL, you will still run your original RedHat EL installation but then update packages rebuilt by Novell. Technically that's the same like adding the CentOS repo config to your RedHat installation and then install all updates from CentOS instead of RedHat. What a mess, why would anyone in the world want this? And then pay $ for the mess...
Same page. They're not installing SUSE, they're offering to support and update RHEL installs.
I know a company that has a few RHEL installs whose RHN subs have expired and which they're updating through CentOS repos. Not anything that I'd be willing to do or support but if Oracle's charging to do something similar to that, they must've tested and tested and tested, and decided that they have a way of doing it reliably.
On Mon, 21 Mar 2011, compdoc wrote:
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
Oh, really ? :-)
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
Please read the previous posts again carefully and the link that was provided:
http://www.novell.com/products/expandedsupport/faq.html
Novell apparently provides (own rebuilt) updates to RHEL3, RHEL4 and RHEL5 for the purpose of supporting your setup for up to three years while you are migrating those systems.
I guess this is a free service so you can stop paying Red Hat as soon as you plan to migrate to SLES. But they expect you to migrate to SLES in the next three years...
So this is not related to OpenSUSE.
I guess this is a free service so you can stop paying Red Hat as soon as you plan to migrate to SLES. But they expect you to migrate to SLES in the next three years.
So this is not related to OpenSUSE.
When I said opensuse, I was referring to suse. Sorry.
The problem I have is that RHEL and SLES are different enough that it's no small thing for a business to make the change.
I'm guessing RHEL 6 and SUSE 11 are at least equal in quality. (I haven't tried either of them) Cost of subscription for each seems close.
So it doesn't make sense that a business would switch - unless maybe the support from Red Hat wasn't great, or if RHEL 6 wasn't great.
I do know that centos 5.5 is great, which in my mind, reflects on Red Hat's ability to produce an excellent product. And they certainly provide releases and updates in a timely manner. So Red Hat isn't resting on its laurels.
Are there that many Red Hat customers ready to jump ship? Does their support suck?
I think both companies should concentrate on providing a good product and decent service, and not waste time on trying to thwart the competition's efforts to provide service to customers.
If they all start trying to hinder each other, it seems the beginning of a war. And the only ones to suffer are IT and the communities. (in other words, the innocent)
Are there that many Red Hat customers ready to jump ship? Does their support suck?
Most RHEL customers do not license it for the phone support, they license it because they run apps that require specific distros for supported operation (like Oracle). If an organization is considering a move to suse then there is probably a non-support related driver.
-David
Am 21.03.2011 15:34, schrieb compdoc:
Not just Oracle. Novell is actively pursuing Red Hat customers and offering to support their Red Hat installations cheaper than Read Hat does. I know a large international technology company which buys RHEL licenses only for the first year and then switches to Novell for support after that.
Does Novell provide their own updates (RHEL rebuilds) or how does this exactly work ? I doubt Novell can redistribute RHEL binaries in this case.
RHEL and opensuse are different - defferent kernels, different config files and slightly different locations for some config files.
It's not like one is a drop in replacement for the other, so it doesn't make sense to me that a business would buy RHEL support and then switch to opensuse.
With all respect, it is even strange to compare RHEL and OpenSUSE because OpenSUSE is for SUSE what Fedora is for RHEL (fast lifecycle, community driven/influenced development platform for the SLES product, which costs for subscriptions as well).
Alexander
Now I have read this thread twice.
:(
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On 3/21/2011 6:19 PM, Jason Pyeron wrote:
Now I have read this thread twice.
:(
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
yeah i'm getting everything in duplicate too.
On 03/20/2011 05:02 PM, aurfalien@gmail.com wrote:
On Mar 20, 2011, at 1:52 PM, William Warren wrote:
On 3/20/2011 3:30 PM, Les Mikesell wrote:
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
exactly. Nothing against Centos but I've deployed my last RH based box. It'll be either Debian or Ubuntu from now on.
I don't get it, why so radical?
Why not go SL and maintain the same methodology?
Not that it matters, but the last time I checked, SL had not released their 4.9 or 5.6 releases either. I am not sure what you are trying to accomplish here.
SL is a fine product and people can use it if they want, but lets not pretend that they are releasing every point release before CentOS.
In fact, I would suggest that someone check the release dates for all version 3.x, 4.x, and 5.x releases for both CentOS and SL (I'll include it in this post)
SL did indeed release a 6.0 before CentOS. For all of the other 25 possible releases, SL released before CentOS on 5 of the 25 times.
Here is the list:
CentOS SL 3.1 03/19/04 05/10/04 3.2 NR 06/28/04 3.3 09/17/04 10/01/04 3.4 01/10/05 02/13/05 3.5 06/09/05 07/26/05 3.6 10/31/05 NR 3.7 04/10/06 05/27/06 3.8 08/25/06 08/02/06 3.9 07/26/07 10/12/07 4.0 03/02/05 04/21/05 4.1 06/15/05 08/26/05 4.2 10/13/05 12/03/05 4.3 03/21/06 05/08/06 4.4 08/30/06 10/10/06 4.5 05/18/07 06/26/07 4.6 12/16/07 03/12/08 4.7 09/13/08 09/03/08 4.8 08/22/09 07/21/09 4.9 03/02/11 NR 5.0 04/12/07 05/07/07 5.1 12/02/07 01/16/08 5.2 06/24/08 06/28/08 5.3 04/01/09 03/19/09 5.4 10/21/09 11/05/09 5.5 05/15/10 05/19/10 5.6 NR NR
Don't get me wrong, SL is a good build and I highly recommend it ... but they do not beat CentOS on releases by months as seems to be insinuated here in the last couple of weeks.
On Mar 22, 2011, at 3:49 PM, Johnny Hughes wrote:
On 03/20/2011 05:02 PM, aurfalien@gmail.com wrote:
On Mar 20, 2011, at 1:52 PM, William Warren wrote:
On 3/20/2011 3:30 PM, Les Mikesell wrote:
On 3/20/11 1:57 PM, Eero Volotinen wrote:
.
I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free.
Yes, but patches (support) cost money, as you might know. Anyway, it is better to pay for real RH instead of oracle linux..
Or, maybe there was back in the days when they released source that matched their binaries... Personally, I think everyone would be better off today if they had turned their back on anything RH-related the day they stopped permitting redistribution of their binaries among the community that created them and made them usable in the first place. I was too lazy to change and Centos made it look reasonable to leave things approximately the same. But, now that RH is putting the screws on anyone who doesn't pay up it is probably time for anyone who cares about free software to rethink things.
exactly. Nothing against Centos but I've deployed my last RH based box. It'll be either Debian or Ubuntu from now on.
I don't get it, why so radical?
Why not go SL and maintain the same methodology?
Not that it matters, but the last time I checked, SL had not released their 4.9 or 5.6 releases either. I am not sure what you are trying to accomplish here.
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
- aurf
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
On Tue, Mar 22, 2011 at 8:54 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
-- Les Mikesell
The change doesn't make anything more difficult for rebuilds.
http://www.channelregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell...
"We haven't at all restricted CentOS's ability to grab source code and recompile it and clean-out trademarks and package it. It's just some of the knowledge of the insides that we're hiding," he [Red Hat chief technology officer Brian Stevens] explains. One longtime CentOS developer agrees.
"I'll not lose sleep on the matter," CentOS co-founder Russ Herold tells The Reg.
http://lists.centos.org/pipermail/centos/2011-March/107338.html
"This should not impact building the kernel ... it might impact things like the CentOSPlus Kernel or CentOS providing a "stop gap" kernel (in the testing repo) while waiting for Red Hat to correct a problem and get their kernel through engineering and then released."
On 3/22/11 8:07 PM, William Hooper wrote:
On Tue, Mar 22, 2011 at 8:54 PM, Les Mikeselllesmikesell@gmail.com wrote:
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
-- Les Mikesell
The change doesn't make anything more difficult for rebuilds.
http://www.channelregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell...
"We haven't at all restricted CentOS's ability to grab source code and recompile it and clean-out trademarks and package it. It's just some of the knowledge of the insides that we're hiding," he [Red Hat chief technology officer Brian Stevens] explains. One longtime CentOS developer agrees.
"I'll not lose sleep on the matter," CentOS co-founder Russ Herold tells The Reg.
http://lists.centos.org/pipermail/centos/2011-March/107338.html
"This should not impact building the kernel ... it might impact things like the CentOSPlus Kernel or CentOS providing a "stop gap" kernel (in the testing repo) while waiting for Red Hat to correct a problem and get their kernel through engineering and then released."
Building the kernel shouldn't be an issue - but look at the SL notes on the srpms that don't build with the listed dependencies as shipped - and they aren't being picky about the library linkages matching the RH binaries like CentOS is. If the RH build links things from source they don't ship, how much can you trust the projects that depend on that source to be able to ship timely updates?
--- Les Mikesell lesmikesell@gmail.com
On Tue, Mar 22, 2011 at 08:18:31PM -0500, Les Mikesell wrote:
Building the kernel shouldn't be an issue - but look at the SL notes on the srpms that don't build with the listed dependencies as shipped
- and they aren't being picky about the library linkages matching the
RH binaries like CentOS is. If the RH build links things from source they don't ship, how much can you trust the projects that depend on that source to be able to ship timely updates?
If you don't trust the project _why_ are you here?
John
On 3/22/11 8:23 PM, John R. Dennison wrote:
On Tue, Mar 22, 2011 at 08:18:31PM -0500, Les Mikesell wrote:
Building the kernel shouldn't be an issue - but look at the SL notes on the srpms that don't build with the listed dependencies as shipped
- and they aren't being picky about the library linkages matching the
RH binaries like CentOS is. If the RH build links things from source they don't ship, how much can you trust the projects that depend on that source to be able to ship timely updates?
If you don't trust the project _why_ are you here?
The CentOS team has a good history and tested binary compatibility has its advantages - but they do rely on the upstream which previously was not openly hostile to rebuilds. It's not necessarily even possible to get binary compatibility if matching source isn't made available.
On 03/22/2011 08:18 PM, Les Mikesell wrote:
On 3/22/11 8:07 PM, William Hooper wrote:
On Tue, Mar 22, 2011 at 8:54 PM, Les Mikeselllesmikesell@gmail.com wrote:
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
-- Les Mikesell
The change doesn't make anything more difficult for rebuilds.
http://www.channelregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell...
"We haven't at all restricted CentOS's ability to grab source code and recompile it and clean-out trademarks and package it. It's just some of the knowledge of the insides that we're hiding," he [Red Hat chief technology officer Brian Stevens] explains. One longtime CentOS developer agrees.
"I'll not lose sleep on the matter," CentOS co-founder Russ Herold tells The Reg.
http://lists.centos.org/pipermail/centos/2011-March/107338.html
"This should not impact building the kernel ... it might impact things like the CentOSPlus Kernel or CentOS providing a "stop gap" kernel (in the testing repo) while waiting for Red Hat to correct a problem and get their kernel through engineering and then released."
Building the kernel shouldn't be an issue - but look at the SL notes on the srpms that don't build with the listed dependencies as shipped - and they aren't being picky about the library linkages matching the RH binaries like CentOS is. If the RH build links things from source they don't ship, how much can you trust the projects that depend on that source to be able to ship timely updates?
This is really nothing new, we have been finding and fixing these kind of things for 8 years.
All it takes is time ... start the build, if it does not build (or if it is linked incorrectly when it builds), figure out why and rebuild.
On Tue, 22 Mar 2011, Les Mikesell wrote:
Building the kernel shouldn't be an issue - but look at the SL notes on the srpms that don't build with the listed dependencies as shipped - and they aren't being picky about the library linkages matching the RH binaries like CentOS is.
If the RH build links things from source they don't ship, how much can you trust the projects that depend on that source to be able to ship timely updates?
Sometimes looking at the list and the posts, I feel like I am watching a group of nuns, talking (speculating) about the life issues of Las Vegas showgirls
In trial building the upstream's '6' sources, about the only circular build dependency that comes to mind was an openMPI / valgrind '-devel' pair that was cross dependent and needed for later packages. It was easy enough to 'bootstrap' around, as the dependencies were not 'versioned' such that a prior valgrind worked just fine to break the circularity
The compulsive obsession on matching every library version exactly is usually just not an issue to most users of any distribution, so long as they do not have a third-party (and non-LSB conformant) application that absolutely positively needs a given library for some reason. Some of the very high end accellerated graphics drivers oriented for some NVidia chipsets in certain blade configurations fall over and die back to non-accelerated, because the driver vendor is calling some non-exposed library interface; some simulation software return slightly varying results out several bits of precision. Other than that, the Unix that we live in is very forgiving with a quick recompile thanks to the FSF / GNU work on the autotools
PLUG: if the darn applications were written to a given LSB level, these issues would go away. But frankly for what one pays for some of these applications, adding a license from upstream is lost in the 'rounding error' of the price /PLUG
I am not against such efforts to match at the library version level [it is articulated as part of what CentOS does], but it is usually not the end of the world when a person has to port around some minor deviation in the build environment
'Mother superior 'Les, later ...
they do rely on the upstream which previously was not openly hostile to rebuilds
It was not always so ... in the early days, there was pushback against the rebuild efforts in general; there is pushback toward commercial 'free-riders' now. This comes and goes, and really there is no substitute for actually 'doing' rather than talking in the cloister
It is not the end of the world when one hits a build problem, as the sources, at the end of the day, are provided, and one can study and read. Indeed, as the collection of Linux variants (and thus soliutons of others to study) out there has grown, it is much easier these days to solve such issues [I solved a cfengine-3.1.4 yesterday with minimal effort]
-- Russ herrold
On 3/23/2011 10:40 AM, R P Herrold wrote:
Sometimes looking at the list and the posts, I feel like I am watching a group of nuns, talking (speculating) about the life issues of Las Vegas showgirls
The showgirls are picky about who they let under the covers. So I suppose we have to wait for the movie version to get the inside story...
It is not the end of the world when one hits a build problem, as the sources, at the end of the day, are provided, and one can study and read.
It is just hard for an outsider to reconcile the statements about the build process not needing any changes or more resources with the lack of a target time. Or that binary compatibility is the critical thing with the distribution becoming incompatible with 3rd party repositories built against upstream's current base. Or that it is easy enough to do by yourself with problems delaying a release. The parts just don't seem to fit together.
On Wed, 23 Mar 2011, Les Mikesell wrote:
It is just hard for an outsider to reconcile the statements about the build process not needing any changes or more resources with the lack of a target time. Or that binary compatibility is the critical thing with the distribution becoming incompatible with 3rd party repositories built against upstream's current base. Or that it is easy enough to do by yourself with problems delaying a release. The parts just don't seem to fit together.
I guess you are saying you are an outsider, Les ... get off the bench talking the game, and start testing
As to the needs of an individual rebuilding the sources, compared to a distribution of CentOS much wider coverage, HughesJr already pointed out that literally millions of machines are affected by a rushed release; exploratory trailling builds for a single build 'scratch' effort are scarcely comparable. There is no reason they SHOULD 'fit together'
Life is like that -- messy and not exact --- I gave two specific examples of binary compatability mattering; on the -devel list a person says they've never seen the problem.
These are not conflicting observations --- just the well known fact that one cannot 'prove' a negative fact
The absence of evidence is not evidence of absence
-- Russ herrold
centos-bounces@centos.org wrote:
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
RH fired at Novell and Oracle, but CentOS and SL are hit by the muzzle blast. I wonder if RH is aware that we're pretty consistent advertizing for RH.
Is there another UV we can call TUV? I don't suppose RH would care if we (CentOS & SL) both disappeared.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Wed, Mar 23, 2011 at 9:14 AM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
centos-bounces@centos.org wrote:
On 3/22/11 7:38 PM, aurfalien@gmail.com wrote:
You missed my point to the poster. While Centos is my defacto production OS, he mentioned switching to Ubuntu which is nothing like RHEL.
So I thought instead of going with such a diff paradigm, that using SL might be more similar in tool set then Ubuntu.
But if the underlying issue is that Red Hat is intentionally making the rebuilds difficult, any derivative is going to be fragile.
RH fired at Novell and Oracle, but CentOS and SL are hit by the muzzle blast. I wonder if RH is aware that we're pretty consistent advertizing for RH.
Is there another UV we can call TUV? I don't suppose RH would care if we (CentOS & SL) both disappeared.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
I think it would bother them. I've repeatedly used CentOS, in a test environment, to then convince companies to purchase RHEL licenses. I've also supported mixed networks of RHEL and CentOS, CentOS on the dev boxes that get all the internal support issues because we do internal abuses to them, and RHEL for production environments.
That's probably..... 300 enterprise licenses, just from me, in all those different environments. And CentOS was a *big* step. And with the CentOS licenses, the clients didn't feel bound to use *only* the official upstream published components: they felt free to experiment, more. (Ask about the Musicbrainz port to CentOS 4, then RHEL 4, if you're curious: asking our favorite upstream vendor to do that one would have been very, very painful.)
On Tue, 22 Mar 2011, Johnny Hughes wrote:
SL did indeed release a 6.0 before CentOS. For all of the other 25 possible releases, SL released before CentOS on 5 of the 25 times.
Right, but as these numbers reveal, since June 2008 Scientific Linux is closing the gap with CentOS (or rather, CentOS is slacking). You can see this when comparing CentOS and RHEL release dates. Since June 2008 CentOS started having longer delays (source: Wikipedia)
https://secure.wikimedia.org/wikipedia/en/wiki/CentOS
Where the average release delay was 25 days before June 2008, the average release delay after June 2008 increased to 51 days, and I am not including the already late CentOS 5.6 and CentOS 6.0 (otherwise it would be 62 days).
CentOS 4.8 (95 days late) and CentOS 5.3 (69 days late) have been the worst delays. But now CentOS 5.6 is already at 69 days and CentOS 6.0 is past 133 days delay, an all time record (not counting CentOS 2 :-)).
So the trend is a decline in release speed and maybe we should lower our expectations. CentOS users have been spoiled in the past.
Kind regards,
On Wed, Mar 23, 2011 at 04:22:36AM +0100, Dag Wieers wrote:
CentOS 4.8 (95 days late) and CentOS 5.3 (69 days late) have been the worst delays. But now CentOS 5.6 is already at 69 days and CentOS 6.0 is past 133 days delay, an all time record (not counting CentOS 2 :-)).
You keep tossing out "late". "late" implies a published deadline and I've yet to see one. I see "best effort" and "will try" comments in many places, but never a published deadline. So, why the focus on "late"?
John
On 23/03/11 03:41, John R. Dennison wrote:
On Wed, Mar 23, 2011 at 04:22:36AM +0100, Dag Wieers wrote:
CentOS 4.8 (95 days late) and CentOS 5.3 (69 days late) have been the worst delays. But now CentOS 5.6 is already at 69 days and CentOS 6.0 is past 133 days delay, an all time record (not counting CentOS 2 :-)).
You keep tossing out "late". "late" implies a published deadline and I've yet to see one. I see "best effort" and "will try" comments in many places, but never a published deadline. So, why the focus on "late"?
I see time-lines clearly published in this FAQ on the CentOS website:
https://www.centos.org/modules/smartfaq/faq.php?faqid=7
Quote: "How long after redhat publishes a fix does it take for CentOS to publish a fix?
Our goal is to have individual RPM packages available on the mirrors within 72 hours of their release, and normally they are available within 24 hours.
Occassionally packages are delayed for various reasons.
On rare occasions packages may be built and pushed to the mirrors but not available via yum. (This is because yum-arch has not been run on the master mirror. This may happen when issues with upstream packages are discovered shortly after their release, and if releasing the package would break it's functionality.)
Update Sets (see this FAQ) will have Security Errata released was stated above, while the BugFix and Enhancement errata are actually tested more rigorisly and released after the new ISO for the Update Set is produced. This will normally be within 2 weeks of the Update Set release."
The above FAQ creates an expectation of 2 weeks being the norm. Equally it is not unreasonable to define any release made after two weeks to be "late" (or later than hoped if you prefer) by the developers own hopes and expectations.
On Wed, Mar 23, 2011 at 06:45:46AM +0000, Ned Slider wrote:
I see time-lines clearly published in this FAQ on the CentOS website:
Trimmed for brevity.
"This will normally be within 2 weeks of the Update Set release."
The above FAQ creates an expectation of 2 weeks being the norm. Equally it is not unreasonable to define any release made after two weeks to be "late" (or later than hoped if you prefer) by the developers own hopes and expectations.
"later than hoped" is a little more on target. You know as well as I do that there has never been a release date published for releases, be they primary or point releases. I read the above as an intended goal, not a hard and fast project time-line; but I will grant that it does lead consumers to expect it within the time frame referenced. That write-up should, in my opinion, be changed to reflect the realities of the situation which are that there are no published release dates and that releases are best-effort affairs.
I just get irritated by seeing nothing but negative comments out of people that have been consumers of the project for years, or in the case of the post that this is a reply to, by someone that was part of the project itself. To be honest I can't recall the last time I saw Dag have anything positive to say about CentOS. Heck, I would like to see 5.6 drop as much as the next guy but I am not, nor for that matter is the overwhelming majority of the user base, crying and complaining about it. Do people honestly think that the constant lambasting as seen here and in the forums is doing anything to get 5.6 out the door faster? Do people think the "suggestions" on the -devel list build motivation for the developers to put in even more hours churning out that which people get for free? If people have nothing positive to say then, please, don't say anything at all.
Seriously... If you don't like how the releases are going then make arrangements to use something else; but please do the rest of us a favor and do so quietly as no one cares to hear about it and it's just more noise for this list. CentOS isn't the only game in town unless binary compatibility with upstream is an organizational requirement; and if that's the case wait for the releases patiently. Or, and here's a truly novel idea, purchase the upstream product. Just realize that _they_ don't publish release dates, either.
If these two alternatives don't meet your needs and you require binary compatibility with upstream then roll up your sleeves, get your hands dirty, and start building the releases yourself. Steps to do so have recently been published on centos-devel and are in the web-accessible archive for that list.
It wasn't all that far in the past that there would be core project members posting on this list fairly regularly; sadly all the negative crap directed at them, both directly and indirectly, has pushed most all of them away. Personally I'd rather they be here and the complainers move on elsewhere.
John
On Tue, 22 Mar 2011, John R. Dennison wrote:
On Wed, Mar 23, 2011 at 04:22:36AM +0100, Dag Wieers wrote:
CentOS 4.8 (95 days late) and CentOS 5.3 (69 days late) have been the worst delays. But now CentOS 5.6 is already at 69 days and CentOS 6.0 is past 133 days delay, an all time record (not counting CentOS 2 :-)).
You keep tossing out "late". "late" implies a published deadline and I've yet to see one. I see "best effort" and "will try" comments in many places, but never a published deadline. So, why the focus on "late"?
John,
The definition of "late" according to many dictionaries:
after the expected or usual time
Let me ask you the same question, why the focus on "late" ?
Kind regards,
Not that it matters, but the last time I checked, SL had not released their 4.9 or 5.6 releases either.
On the other hand, unlike CentOS, Scientific Linux (SL) is backporting 5.6 security fixes. Indeed, all of the security issues CentOS 5.5 has right now aren't in SL.
SL is a fine product and people can use it if they want, but lets not pretend that they are releasing every point release before CentOS.
They haven't. Indeed, before 2009 they significantly lagged behind CentOS. However, for the last two years, every SL release has been on before the CentOS release, or within two weeks of the CentOS release.
[Left column CentOS release date, right column SL release date.
4.8 08/22/09 07/21/09 4.9 03/02/11
For 4.9, I say "not applicable"; SL is current with security fixes, and, as I understand it, 4.9 is just 4.8 + security fixes. Indeed, CentOS isn't mastering iso images for 4.9.
5.3 04/01/09 03/19/09
Within two weeks.
5.4 10/21/09 11/05/09
SL was two weeks after the CentOS release.
5.5 05/15/10 05/19/10
CentOS won--by all of four days.
Don't get me wrong, SL is a good build and I highly recommend it ... but they do not beat CentOS on releases by months as seems to be insinuated here in the last couple of weeks.
SL is tied with CentOS for all 2009, 2010, and 2011 releases. What tips the scales in SL's favor is that they have a solid policy in place to have timely security updates:
https://www.scientificlinux.org/documentation/faq/errata
And, yes, I am repeating myself, but all 5.6 security updates are available for SL 5.5 users until they can master some SL 5.6 ISO images. This has been SL's policy for over a couple of years:
http://ever-increasing-entropy.blogspot.com/2009/08/perfect-illustration-of-...
I blogged about why I am in the process of making the switch to SL here:
http://samiam.org/blog/20110319.html
---
As an open-source developer, I understand the frustration of working hard and having a lot of freeloaders not appreciating my work. I feel people posting here talking about how unprofessional CentOS is acting are completely missing the point: CentOS is acting unprofessional because, well, they aren't being paid. Being professional means that money is changing hands.
A person does not get treated like a customer unless they are paying customer. Just as most restaurants don't allow people to sit at their tables unless they order something, open source developers have no obligation whatsoever to their users unless said users appropriately compensate them for their time.
CentOS has no obligation to ever make another security patch again. They have no obligation to release 5.6, 6.0, or any other release of their software. Quite frankly, I think Karanbir Singh would be in his right to say "Listen, I need to spend more time with my family and can not continue working on CentOS unless I get paid for my time".
Yeah, a lot of freeloaders would flame him for asking for money (look at the flame fest the Nexuiz developers got when they commercialized their open-source game), but this is a perfectly healthy boundary for an open-source developer to establish.
Some developers don't like announcing boundaries like that; a lot of open source projects never formally die. They have this way of becoming inactive without any formal announcements and just floundering. I've seen this tape played many times before:
http://maradns.blogspot.com/2009/09/rant-putting-closure-on-project.html
Another example is djbdns, which is over ten years old; the last formal release of djbdns has three known security holes:
http://samiam.org/blog/20110103.html
- Sam
On Wed, Mar 23, 2011 at 2:29 AM, Sam Trenholme strenholme.usenet@gmail.com wrote:
As an open-source developer, I understand the frustration of working hard and having a lot of freeloaders not appreciating my work. I feel people posting here talking about how unprofessional CentOS is acting are completely missing the point: CentOS is acting unprofessional because, well, they aren't being paid. Being professional means that money is changing hands.
Being a professional isn't just a question of money; it's also a question of attitude and presentation.
The developers' "use something else if you're unhappy" replies are unprofessional, no matter what their level of frustration with the criticism being directed at them might be.
On Wed, Mar 23, 2011 at 4:54 AM, Tom H tomh0665@gmail.com wrote:
On Wed, Mar 23, 2011 at 2:29 AM, Sam Trenholme strenholme.usenet@gmail.com wrote:
As an open-source developer, I understand the frustration of working hard and having a lot of freeloaders not appreciating my work. I feel people posting here talking about how unprofessional CentOS is acting are completely missing the point: CentOS is acting unprofessional because, well, they aren't being paid. Being professional means that money is changing hands.
Being a professional isn't just a question of money; it's also a question of attitude and presentation.
The developers' "use something else if you're unhappy" replies are unprofessional, no matter what their level of frustration with the criticism being directed at them might be.
Developer, singular. It's just Johnny doing that.
On 03/20/2011 12:30 PM, Les Mikesell wrote:
Or, maybe there was back in the days when they released source that matched their binaries
Red Hat's published source is what they use to create their binaries. There is no mis-match.
On 3/25/2011 4:38 PM, Gordon Messmer wrote:
On 03/20/2011 12:30 PM, Les Mikesell wrote:
Or, maybe there was back in the days when they released source that matched their binaries
Red Hat's published source is what they use to create their binaries. There is no mis-match.
I thought the issue causing the delays is that rebuilding from the source does not reproduce their binaries unless you introduce library versions that aren't what the source creates.
On Fri, Mar 25, 2011 at 5:49 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/25/2011 4:38 PM, Gordon Messmer wrote:
On 03/20/2011 12:30 PM, Les Mikesell wrote:
Or, maybe there was back in the days when they released source that matched their binaries
Red Hat's published source is what they use to create their binaries. There is no mis-match.
I thought the issue causing the delays is that rebuilding from the source does not reproduce their binaries unless you introduce library versions that aren't what the source creates.
One has to be cautious about the bootstrap environment, to make sure that the libraries available in your "mock" or other build environments are the same libraries. Red Hat seems to be very, very good about this. Scientific Linux isn't so careful in their recompilation, something that's been documented here recently, but it's why I want access to the "/etc/mock/" setups and the non-existent source control for tweaked packages.
On 3/25/2011 5:03 PM, Nico Kadel-Garcia wrote:
Or, maybe there was back in the days when they released source that matched their binaries
Red Hat's published source is what they use to create their binaries. There is no mis-match.
I thought the issue causing the delays is that rebuilding from the source does not reproduce their binaries unless you introduce library versions that aren't what the source creates.
One has to be cautious about the bootstrap environment, to make sure that the libraries available in your "mock" or other build environments are the same libraries. Red Hat seems to be very, very good about this.
It is not that they are good, they are the authority. Whatever library version happened to be in their build root when the linkage was done is correct by definition even if it isn't what you get when you build that library from source and/or it isn't specified as a dependency.
On Fri, Mar 25, 2011 at 6:26 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/25/2011 5:03 PM, Nico Kadel-Garcia wrote:
Or, maybe there was back in the days when they released source that matched their binaries
Red Hat's published source is what they use to create their binaries. There is no mis-match.
I thought the issue causing the delays is that rebuilding from the source does not reproduce their binaries unless you introduce library versions that aren't what the source creates.
One has to be cautious about the bootstrap environment, to make sure that the libraries available in your "mock" or other build environments are the same libraries. Red Hat seems to be very, very good about this.
It is not that they are good, they are the authority. Whatever library version happened to be in their build root when the linkage was done is correct by definition even if it isn't what you get when you build that library from source and/or it isn't specified as a dependency.
And they're very good about making sure that they've correctly "bootstrapped" their systems, that their "build" environment matches the components of the available, rebuilt packages. This was a deadly problem in the early days of compilers, when to build gcc, you basically had to build it *4* times to make sure the new gcc compiler was used to build the new gcc compiler, which rebuilt the gcc compiler, and then the fourth one was compared to the third one to make sure it matched.
That takes work, system resources, and some understanding of how to resolve dependencies. It's especially tricky when several packages will all satisfy the same dependencies. (Don't get me *STARTED* on JDK mismatches!!!!) And it's doubtless how those Scientific Linux "libtalloc" discrepancies crept in.
On 3/25/11 6:31 PM, Nico Kadel-Garcia wrote:
One has to be cautious about the bootstrap environment, to make sure that the libraries available in your "mock" or other build environments are the same libraries. Red Hat seems to be very, very good about this.
It is not that they are good, they are the authority. Whatever library version happened to be in their build root when the linkage was done is correct by definition even if it isn't what you get when you build that library from source and/or it isn't specified as a dependency.
And they're very good about making sure that they've correctly "bootstrapped" their systems, that their "build" environment matches the components of the available, rebuilt packages.
If that were true, you should be able to duplicate their linkages exactly by priming the 1st build run with (all of) their binaries, then rebuilding with your own output results instead. But then everything would be done by now. So I don't think that's true.
On Fri, Mar 25, 2011 at 9:34 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/25/11 6:31 PM, Nico Kadel-Garcia wrote:
One has to be cautious about the bootstrap environment, to make sure that the libraries available in your "mock" or other build environments are the same libraries. Red Hat seems to be very, very good about this.
It is not that they are good, they are the authority. Whatever library version happened to be in their build root when the linkage was done is correct by definition even if it isn't what you get when you build that library from source and/or it isn't specified as a dependency.
And they're very good about making sure that they've correctly "bootstrapped" their systems, that their "build" environment matches the components of the available, rebuilt packages.
If that were true, you should be able to duplicate their linkages exactly by priming the 1st build run with (all of) their binaries, then rebuilding with your own output results instead. But then everything would be done by now. So I don't think that's true.
I'm speaking up for our CentOS repackagers here. That kind of bootstrapping takes cycles and practice, and double checking. In theory, they could. Our CentOS rebuilders have exposed a few dependencies for which the SRPM's are not published (and which our favorite upstream vendor is fixing them, but they *don't have to!!!*. That's not part of a GPL license, it's just good free software practice.) And they do have to spend time re-arranging centos-release to publish yum repositories. [ RHEL does it differently, with that "up2date in grandma's clothing" known as yum-rhn-plugin. I vastly prefer the genuine yum repository approach used by CentOS. ] And they legally need to refactor, oh, what? A couple of dozen of packages to handle trademarks and upstream references?
It's not easy work. I'd love to help, but keep not seeing little components like the mock configurations.
On Friday, March 25, 2011 09:55:34 pm Nico Kadel-Garcia wrote:
I'm speaking up for our CentOS repackagers here. That kind of bootstrapping takes cycles and practice, and double checking. In theory, they could. Our CentOS rebuilders have exposed a few dependencies for which the SRPM's are not published (and which our favorite upstream vendor is fixing them, but they *don't have to!!!*. That's not part of a GPL license, it's just good free software practice.)
Let me speak up for our CentOS devs too, as the upstream doesn't have to bootstrap in this way. Their bootstrap dates from Mother's Day.
Fedora likewise; they have a previous version, and rolling binaries that are pretty well depsolved already. The rebuilders are the ones who have it more difficult, as they have to reproduce a build sequence from a known snapshot point (the last public beta).
And the *distribution* as a whole is not covered by the license you might think it is.
Les, the upstream source RPMs aren't even the "source source" for the upstream build; SRPMS are just a by product of the build of the binaries from source in an SCM (managed by Red Hat's koji), and in theory, given the same identical environment that built the upstream binaries they will re-build to the same binary. The environment is the hard thing to replicate, since it is a moving target, and each build changes it slightly. It's questionable if upstream could exactly replicate it from their own source RPM's without significant effort (that is, outside of koji).
To their credit they fix those sort of bugs in due time, but as mentioned they are not bound by any license to do so, since the binary build environment isn't part of the 'source code.'
Karanbir and Johnny have both posted at length about this issue; Russ as well.
What's interesting is the length of time it's taking SL as well to get 4.9 and 5.6 out in GA, as well as CentOS with a GA for 5.6 and 6.0. It seems to be pretty soon due, at least 5.6.
As it stands, SL has a GA 6.0, and CentOS has a GA 4.9. I like many others am waiting for that middle piece, a GA 5.6. But I'd rather have it correctly done than quickly done if I have to choose.
On 3/26/11 12:44 PM, Lamar Owen wrote:
Les, the upstream source RPMs aren't even the "source source" for the upstream build; SRPMS are just a by product of the build of the binaries from source in an SCM (managed by Red Hat's koji), and in theory, given the same identical environment that built the upstream binaries they will re-build to the same binary. The environment is the hard thing to replicate, since it is a moving target, and each build changes it slightly. It's questionable if upstream could exactly replicate it from their own source RPM's without significant effort (that is, outside of koji).
I don't see how you could miss if you did a 2nd rebuild where the libraries populating the build environment are the product of the source you are shipping (correct dependency listings or not). Or how you can claim to be shipping source that matches your binaries if you don't do it that way. Does an rpmbuild --rebuild of one of the packages in question on a stock RH system create a binary that would fail the CentOS QA?
On Sat, Mar 26, 2011 at 2:53 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/26/11 12:44 PM, Lamar Owen wrote:
Les, the upstream source RPMs aren't even the "source source" for the upstream build; SRPMS are just a by product of the build of the binaries from source in an SCM (managed by Red Hat's koji), and in theory, given the same identical environment that built the upstream binaries they will re-build to the same binary. The environment is the hard thing to replicate, since it is a moving target, and each build changes it slightly. It's questionable if upstream could exactly replicate it from their own source RPM's without significant effort (that is, outside of koji).
I don't see how you could miss if you did a 2nd rebuild where the libraries populating the build environment are the product of the source you are shipping (correct dependency listings or not). Or how you can claim to be shipping source that matches your binaries if you don't do it that way. Does an rpmbuild --rebuild of one of the packages in question on a stock RH system create a binary that would fail the CentOS QA?
"rpmbuild --rebuild" need not work. Dependencies need not be satisified by anything Red Hat publishes, and this has happened and been documented (and addressed in patches upstream).
I went slightly nutso with similar issues when I published an updated "nx.spec" for CentOS 6 in Bugzilla. There are dependencies on audio related "devel" packages which are not on RHEL 6.0 installation media, but only available in the "optional" channel of yum-rhn-plugin. CentOS, sensibly, doesn't make these funny distinctions and puts all such publicly licensed packages in one main "os" repository. This can save a lot of nuttiness when trying to build such packages in mock, but for a while there I thought they hadn't published the darn thing.
On Saturday, March 26, 2011 02:53:19 pm Les Mikesell wrote:
Does an rpmbuild --rebuild of one of the packages in question on a stock RH system create a binary that would fail the CentOS QA?
This is the core of the question. As I don't have an RHEL 6 system available to try, I can't directly answer that.
The answer is 'it depends'. But you still miss the issue; the buildroot repository is the binary tree built against, and it could contain binaries that are different from the shipped RHEL system's binaries. Of course, that's with mock, which makes it easier to make something that is not self-hosted; it also makes it possible to build multiple versions of systems on a single buildhost running yet a different version.
Straight rpmbuild --rebuild may very well fail with missing build dependencies, which you would then have to go spelunking for in non-RHEL repositories (but they're out there, or SL6 wouldn't be built at all, now would it?). You have the exact source code used to build the package you have installed; you may or may not have all of the same versions of the dependencies that your binary package actually was built against.
The question can be distilled as 'is RHEL self-hosting' to which the answer has been for a while 'No, and that isn't a primary goal of RHEL.'
"Why not?" would be a reasonable question right about now.
To use an example I work with, current Ardour 3 source code out of subversion (Ardour 3 is in alpha test, and is not released) cannot be compiled against just any version of the JACK development headers and libraries; to get a working executable, you have to compile against a specific version of the jack-devel package; but the built binary can run with any recent version of the JACK library. An Ardour 3 binary could be built and shipped that would work fine with the current JACK 1.96 but was built with 0.120.1 (which is the specific version required for the build to be successful). I would give you a link, but the current 'ardour-dev' archive is only available to members of that list.
The point being, there are likely reasons other than carelessness or obfuscation-ness that a package might be built against development headers and libs that are different from the shipping versions (but with compatible sonames, perhaps), or maybe built with a different toolchain (compiler, linker, etc) than the shipping version of those tools, perhaps in order to just get the package to build; it will run fine with the shipping binaries, but may not build with them. And it may be a niche thing, where other packages in the distribution won't build with that particular toolchain....
I'll finish by pointing to the following resources for learning more about this (and I'm just throwing these out, I've not thoroughly checked everything said in these pages, but notice who is posting in some cases):
http://adsm.org/lists/html/Veritas-bu/2010-07/msg00135.html http://www.redhat.com/archives/rhl-list/2004-January/msg02812.html http://www.redhat.com/archives/taroon-beta-list/2003-September/msg00038.html http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00072.html http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00073.html http://www.redhat.com/archives/nahant-list/2006-July/msg00059.html http://www.redhat.com/archives/taroon-list/2004-March/msg00249.html http://www.redhat.com/archives/taroon-list/2004-March/msg00261.html http://www.redhat.com/archives/nahant-list/2006-May/msg00266.html http://www.redhat.com/archives/nahant-list/2006-May/msg00264.html (side note on that last one.... there was and maybe still is a 'Cisco Enterprise Linux' build......reference: http://fr2.rpmfind.net/linux/RPM/sourceforge/p/project/pi/pipeviewer/OldFile... ) http://www.redhat.com/archives/taroon-list/2005-March/msg00222.html http://www.redhat.com/archives/taroon-list/2005-March/msg00228.html http://www.redhat.com/archives/nahant-list/2006-May/msg00273.html
There are more.
Александр Кириллов wrote:
CentOS has no clients to whom a contractual duty of support is owed. If SLAs, sales engineers, 800 numbers, and such are wanted or needed, PLEASE buy a contract from someone
TANSTAAFL
And yes I started looking elsewhere and with reasonably priced offer from Oracle this project is probably dead in the water.
Hi AK,
Why would you swing so radically in the other direction from free to fee?
Have you looked at SL? They don't have 5.6 but seem to be on a stable 6.0 rel.
Hi,
I'm not actually looking for free. I'd gladly support the efforts of our "prominent North American Enterprise Linux vendor" with what little I have if their offers wouldn't be so ridiculously expensive. I hope the situation may change now with Oracle in direct competition with RH for RH and RH-based distros user base. BTW Oracle offers installable binaries for free. I didn't get into details yet but this sounds like a viable alternative.
<rant> Scary how our society's ethics and decisions are driven by money. Pay less money - must be better - right even. So easy to forget the reason this debate turns up every 10 days or so - Oracle and others have been free-loading on RH and in order to survive RH had to take some action - action that in large part contributes to the delay so many complain about. Why is it that we don't see the issue that really has driven all this - A large unethical corporation has taken a free ride on the open-source community and stuffed it up for all of us. The cost of doing all the things that RH does, and contributing so much to the open-source community is paid for by those that need on-call support and responsiveness. Now along comes an unethical corporation that sees an opportunity to make some more money - doing what is right doesn't come into the equation As I said at the beginning of my rant - if it makes money it must be right - if it looses money or makes less money it must be wrong. Please don't put the blame in the wrong place - punish the real villain - buy something other than oracle! </rant>
AK
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
TANSTAAFL
... long overdue "free lunch"
I get it -- you dont (or choose not to) understand the written word
Yeah, the picture's pretty bleak. The world's climates are changing, the mammals are taking over, and we all have a brain about the size of a walnut.
On Sun, 2011-03-20 at 20:30 +0300, Александр Кириллов wrote:
The point is it's probably as easy to lose a "community" if this still matters to the core CentOS team.
Centos offers free and very reliable Linux with free and very reliable updates.
The people providing this free service are volunteers.
And yes I started looking elsewhere and with reasonably priced offer from Oracle
You come here for the free and very reliable product whilst wanting to spend money on a different product. Perhaps you should have spent your money several months ago and then subscribed to the Oracle mailing list?
I come here because I like Centos. I admire and respect the volunteers who make Centos the great product it is. I've seen it used all around the world running Apache.
this project is probably dead in the water.
Nonsense. Centos is definitely not about to die. Especially not with some still on version 4.9 ;-) Versions 5.6 and 6 will come. 6 will be useful because it has a latter kernel adapted for the Arduino microcomputer boards.
Good luck with Oracle. Hope it makes you happier.
With best regards,
Paul. England, EU.
Le 20/03/2011 19:36, Always Learning a écrit :
On Sun, 2011-03-20 at 20:30 +0300, Александр Кириллов wrote:
The point is it's probably as easy to lose a "community" if this still matters to the core CentOS team.
Centos offers free and very reliable Linux with free and very reliable updates.
With no updates since more than three months (for 5.6), and no news from the core team on the progress or difficulties, do you still consider it as "very reliable" ?
For a free project and work done by volunteers, you cannot ask the job been done for a given date. It is "best effort", and cannot be completly be reliable.
But when the core team refuse to give any update (no news) at all (black out), since more than one week, I consider this as even less reliable...
Alain
On Sun, Mar 20, 2011 at 09:00:54PM +0100, Alain Péan wrote:
But when the core team refuse to give any update (no news) at all (black out), since more than one week, I consider this as even less reliable...
Stop this nonsense, would you? We rehash this same crap every few weeks and it's ridiculous.
Yes, the project is reliable. No, the project isn't going anywhere. No, you don't have a gun to your head and if you are unhappy you are free to move on elsewhere.
John
But when the core team refuse to give any update (no news) at all
(black
out), since more than one week, I consider this as even less
reliable...
Stop this nonsense, would you? We rehash this same crap every few weeks and it's ridiculous.
And this same crap it is.
On Sun, Mar 20, 2011 at 08:30:41PM +0300, Александр Кириллов wrote:
And yes I started looking elsewhere and with reasonably priced offer from Oracle this project is probably dead in the water.
Hahahaha.
Thanks for the chuckle. Do you have an encore performance prepared?
John
On Sun, Mar 20, 2011 at 11:56 AM, R P Herrold herrold@owlriver.com wrote:
On Sun, 20 Mar 2011, Nico Kadel-Garcia wrote:
There are significant components of the upstream 5.6 release which are stuck behind the CentOS 5.6 release process, but are now incorporated in EPEL 5 components.
Sad that -- that the dependent partial Red Hat adjunct project is not compatible with people not using Red Hat's product
Whoa, there. Try to be as careful with branding it as our faithful CentOS maintainers are with their branding. It's a *volunteer* effort, much like CentOS (with a much broader set of tasks and goals). It's a very, very useful and worthwhile project, and profoundly extends the useful lifespan of RHEL, CentOS, Scientific Linux, and any other upstream based vendor distributions, and a great testing place for software for the next upstream vendor major releases. It's very much worth cooperating with EPEL, it's compatibility with that upstream vendor is *excellent*, and they're playing it just right.
Since the php53 package is in the "upstream vendor" published codelines and updates, there's no reason not to include it in EPEL dependencies. The out-of-date php-5.1 codeline is years old, and the approach is reasonable, and has been used before for samba (which had samba3x), gcc (which had gcc43 and gcc44 in CentOS releases), and bind97 (which is still pending the CentOS 5.7 release).
So there's precedent, and a pattern, for including such updates in the upstream vendor's codelines. Unfortunately, right now, it's all blocked in CentOS by the not-yet-announced 5.6 code release. I'd like to see that block lifted on a case by case basis, if feasbile. I've personally tested this php53 package against CentOS 5.5, and it works well and resolves the dependency.
Note that Scientific Linux is publishing these updates in a much more up-to-date, rolling fashion. I don't want to switch to that distribution, because the line-for-line compatibility between CentOS and that "upstream vendor" is better, and reassuring to people when I try to get them to switch from one to the other for support reasons. But if I have to, because these updates are blocked for so long, I'll have to take all my testing and bug reports over there. I don't have resources to help yet another distro.
The unpleasantness of reading continual criticism, from those who will not do the minimal local rebuilds, to use the packages from a project not affiliated with the CentOS project, has pretty effectively driven the CentOS core developers away from this mailing list
I *just did* the local rebuilds, and tested them. They work. I want them in the available upstream repositories, which they're not.
The "testing" repository is not available by default, and is not generally mirrored. Should it be, by being included in the main websites in their own folder? That would make such "testin" components available to the rest of us.
Niko, I notice you did out post your 'helpful criticism' to which I respond, on the EPEL list on how to do the workaround EPEL's policies of not shipping packages competing with Red Hat's enterprise product. Perhaps they would welcome it (probably not, as they consciously DO NOT COMPETE with the parent product)
RHEL and Scientific Linux do not have this issue, due to the up-to-date php53 access. CentOS does. It's therefore a CentOS issue, not an EPEL issue, although if you point me to the EPEL list message, I'll be happy to follow up there.
If a person doesn't like CentOS's pace and attention to shipping durable and 'correct' releases or with different features (as with EPEL), or want packages faster than CentOS' rate, PLEASE encourage them to either learn to show some minimal self-reliance in building, or to not use CentOS as a base
I've said *nothing* against the attention to detail. The pace, however, is becoming problematic. The upstream vendor does not separate the updates by minor release number, and hasn't done that since Red Hat 9. CentOS does not have to emulate.
In fact, hey! I just tested a component and announced the results to solve a specific compatibility problem!
I don't see the problem here. I just tested this and it works fine. The drupal6 package only requires php 5.2 or greater.
This is out of the drupal6-date.spec file
Requires: drupal6 >= 6.0, drupal6-cck, php >= 5.2
You can get php52 or php53 from the IUS repository. Install the IUS repo from http://iuscommunity.org/ http://wiki.iuscommunity.org/Doc/ClientUsageGuide
Install the yum-plugin-replace package and follow the instructions.
ps. Somewhere there is a dozen people in a Red Hat conference room reading this list laughing their heads off. Don't give them more fuel. The CentOS team will get 5.6 out soon enough.
On 03/20/2011 11:23 AM, Nico Kadel-Garcia wrote:
There are significant components of the upstream 5.6 release which are stuck behind the CentOS 5.6 release process, but are now incorporated in EPEL 5 components. In particular, the "php53" package is now necessary for the "drupal6" EPEL components, due to the long out of date PHP 5.1 in the default upstream vendor's codebase.
On Mon, Mar 21, 2011 at 12:51 AM, Matthew Feinberg matthew@choopa.com wrote:
I don't see the problem here. I just tested this and it works fine. The drupal6 package only requires php 5.2 or greater.
Right. The php53 package is in the upstream vendor's updates, all of which are held up for CentOS release behind the 5.6 release. I'd like to see it get somewhere into the CentOS 5.5 releases, even if it's one of a select few components in the "updates" that are published in the 5.5 release.
It's hard to consider CentOS "equivalent to the upstream vendor's OS" if the updates are so far behind that commonly available packages are incompatible with it.
On 03/21/2011 07:08 AM, Nico Kadel-Garcia wrote:
On Mon, Mar 21, 2011 at 12:51 AM, Matthew Feinberg matthew@choopa.com wrote:
I don't see the problem here. I just tested this and it works fine. The drupal6 package only requires php 5.2 or greater.
Right. The php53 package is in the upstream vendor's updates, all of which are held up for CentOS release behind the 5.6 release. I'd like to see it get somewhere into the CentOS 5.5 releases, even if it's one of a select few components in the "updates" that are published in the 5.5 release.
It's hard to consider CentOS "equivalent to the upstream vendor's OS" if the updates are so far behind that commonly available packages are incompatible with it.
So ... go away and don't use it. Is someone forcing you to use CentOS?
What other distribution that is free has released their 5.6 release?
-
Alain Péan -
Alexander Dalloz -
Always Learning -
aurfalien＠gmail.com -
Brunner, Brian T. -
compdoc -
Dag Wieers -
David Brian Chait -
Drew -
Eero Volotinen -
Gordon Messmer -
Jason Pyeron -
John R. Dennison -
Johnny Hughes -
Lamar Owen -
Les Mikesell -
Marko A. Jennings -
Matthew Feinberg -
Ned Slider -
Nico Kadel-Garcia -
R P Herrold -
R P Herrold -
Rob Kampen -
Sam Trenholme -
Simon Matter -
Tom H -
William Hooper -
William Warren -
Александр Кириллов