On Wed, Feb 26, 2014 at 9:33 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
And eventually you'll run into a conflict in updates or the update will pull in a version of something with surprising differences - and not having that kind of breakage is the main reason to start with CentOS in the first place. If you were advising someone else how to set up their first Centos box, think about how long that conversation has to be, and how strange it all seems that the repositories set up to help people do not stay coordinated with each other and thus are likely to eventually cause trouble. Even ones that don't replace core packages don't track each other.
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Yes, very often it is. If you build under /usr/local as most source packages do, it won't break your system updates. If instead, you get a yum conflict and don't know how to fix it, you'll never get any security fixes again.
Ultimately, responsibility lies on user. He is the owner of the system, and he will do what ever needs to be done. And since CentOS/RHEL does not provide MANY things (EPEL is 2 TIMES LARGER then Base + Updates repositories, and elrepo has 260 packages so at least 150 distinct drivers NEEDED by community).
Yes, you understand the problem. RHEL/CentOS are not suitable for casual users who don't want to dedicate their lives to tracking where to find packages and which repositories play well with others. Everyone here talking about it is a professional who does that sort of thing, but frankly there are better things to do.
So when one stupid newbie created blog entry explaining that CentOS does not have that package, so you need to recompile it, and gives you step-by-step howto, something is wrong.
No, that is exactly the state of affairs that you should expect from the current situation.
But when there is MORE such pages/blogs then "install it from 3rd party repository we wish not to name so there are no favorites...", then you have a HUGE problem. And solution is to REDUCE the number of problematic blogs/pages, not increase them doing absolutely nothing. "Prime directive" (Star Trek reference) is all excellent and shiny, but does not solve people getting burned anyway, and teaching others the wrong way in the process.
The blog pages are an effect, not the cause of the situation. The cause is that EPEL policy keeps out many packages that are needed - and that's not going to change unless they change locations/ownership or US law changes. Other repos don't stay strictly coordinated with EPEL, and from historical accounts that seems to be impossible.
- Do you agree that release packages for only EPEL and ElRepo
repositories are provided, but not other repositories, I am guessing 80-90% will vote yes, and you will have community approval as a basis for any question other repositories might raise.
Yes, unless there is some assurance of a policy in other repos that they will remain coordinated with those 2 in addition to not replacing base packages. Making yum stop getting security updates is about the worst thing that can happen to a box.
I would be happy with something just resembling the CentOS name (DentOS. PentOS, ...), but on the same resources as CentOS (either using CentOS packages as a base or rebuilding it under another brand while building CentOS packages) so there is newbie-friendly version that allows 3rd party repositories. And I am guessing that this approach would mean most people would choose this enhanced version of CentOS over original CentOS, exactly because of out-of-the-box experience.
The problem isn't the base contents. It is the lack of strict coordination among 3rd party repos. Either a single repo needs to include all of what EPEL provides plus the things their policy excludes (probably not permitted) or the other repos need to stay strictly coordinated and conflict free (probably not possible).
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
This is no equivalent for the coordination among the additional repositories that you can enable for debian/Ubuntu. And there is no 'proper' way to do the equivalent of installing those additional packages under RHEL/CentOS because there can be no expectation that wherever you'd suggest getting them will not cause update conflicts.
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
I haven't seen any issues that would solve by itself.