I don't see the issue as black and white as dizwell. RedHat's packaging does what I want (creates a "Server with GUI" without libreoffice) but it does this because of a "bug"… they omit unoconv and libreoffice from their "server" DVD despite them being listed in their comps.xml file as dependencies. If RedHat created an "Everything" DVD, it would create a "Server with GUI" that included libreoffice, according to their own comps.xml file.
Unfortunately, I don't think we are really comparing apples to apples here. RedHat has a "server" DVD that (due to a fluke) does what we desire and seems optimized for a server environment. I think dizwell's beef is that CentOS' regular DVD seems to be more optimized for a "workstation" rather than "server" environment.
My beef is that the "Server with GUI" using the "Everything" DVD results in a bloated server with libreoffice. But I have since come to realize this is really a bug in RedHat's part of the mix (possibly by design).
In case anyone is wondering why I'm stuck on the "Server with GUI"… I know it's not real conventional to have a GUI on a server. I'm studying Michael Jang's book on RHCSA/RHCE Study Guide. His book covers how to do things both from the CLI and GUI when possible. I can't wait until they come out with a version of the book that covers EL 7.
By the way, thanks TrevorH and gerald_clark for your numerous helpful posts!
No 32bit packages?
Re: No 32bit packages?
The reality is that Oracle linux includes more 32 bit packages because they need it if an Oracle customer installs Oracle 11g or 10g and associated software. Some of that software is required to run Oracle. And really you should be pleased that CentOS has leaned out their install of the extraneous 32 bit software. 32 bit software is on its way out.
Re: No 32bit packages?
I think dizwell's beef is that CentOS' regular DVD seems to be more optimized for a "workstation" rather than "server" environment.
Don gets it in one, I think.
It's not a strawman to point out that if you click the option to download "the DVD", you don't get something which is entirely fit for Oracle server use (but you would have in CentOS 6.5 days, and Red Hat and Oracle both manage to produce a single DVD download that works for that purpose, too, even with 7.0).
Yes, of course there's the Everything ISO to use, but it's 2.something GBs bigger than it needs to be (for the purposes of building a server that can run the Oracle database stack, that is). And yes, I can download dependencies via yum on an as-needed basis if I happen to have a direct connection to the Internet. No-one was suggesting an Oracle server was impossible to build. Just that CentOS's choice of package distribution uniquely (amongst the Enterprise Linux clones) makes it harder than it needed to be.
Don't continue the discussion on my account, anyway. My original question was simply to ask for pointers to where these sorts of packaging decisions were thoughtfully deliberated and decided on... and I've got my answer (that it appears no such deliberations took place or are available).
In the light of that answer, and the fact that CentOS is uniquely harder to turn into an Oracle server than either of the other two Enterprise Linux distros (RHEL and OEL), it is a simple matter for me to drop CentOS as my primary development platform and recommend people to use OEL instead. It doesn't mean CentOS 7 is bad or "unfit for purpose" generally: simply, that for the specific business of building Oracle servers, there are better free options out there now. Maybe the developers would keep this sort of use-case in mind next time they decide to package things quite differently from upstream? Just a suggestion.
Don gets it in one, I think.
It's not a strawman to point out that if you click the option to download "the DVD", you don't get something which is entirely fit for Oracle server use (but you would have in CentOS 6.5 days, and Red Hat and Oracle both manage to produce a single DVD download that works for that purpose, too, even with 7.0).
Yes, of course there's the Everything ISO to use, but it's 2.something GBs bigger than it needs to be (for the purposes of building a server that can run the Oracle database stack, that is). And yes, I can download dependencies via yum on an as-needed basis if I happen to have a direct connection to the Internet. No-one was suggesting an Oracle server was impossible to build. Just that CentOS's choice of package distribution uniquely (amongst the Enterprise Linux clones) makes it harder than it needed to be.
Don't continue the discussion on my account, anyway. My original question was simply to ask for pointers to where these sorts of packaging decisions were thoughtfully deliberated and decided on... and I've got my answer (that it appears no such deliberations took place or are available).
In the light of that answer, and the fact that CentOS is uniquely harder to turn into an Oracle server than either of the other two Enterprise Linux distros (RHEL and OEL), it is a simple matter for me to drop CentOS as my primary development platform and recommend people to use OEL instead. It doesn't mean CentOS 7 is bad or "unfit for purpose" generally: simply, that for the specific business of building Oracle servers, there are better free options out there now. Maybe the developers would keep this sort of use-case in mind next time they decide to package things quite differently from upstream? Just a suggestion.