Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: atrpms: users

Choosing between sl6 and CentOS 6

 

 

atrpms users RSS feed   Index | Next | Previous | View Threaded


J.Pilk at tesco

Nov 19, 2011, 9:46 AM

Post #1 of 3 (313 views)
Permalink
Choosing between sl6 and CentOS 6

I'm thinking of installing one of these on a 'new' 32-bit laptop and
would like to know what technical differences exist between their
ATrpms builds. ISTR that years ago SL was built for systems with larger
memory, but I haven't found anything that confirms this now. I suppose
it must lurk in the spec files somewhere, but is there a handy explanation?

John P

_______________________________________________
atrpms-users mailing list
atrpms-users [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-users


Axel.Thimm at ATrpms

Nov 19, 2011, 10:52 AM

Post #2 of 3 (297 views)
Permalink
Re: Choosing between sl6 and CentOS 6 [In reply to]

On Sat, Nov 19, 2011 at 05:46:34PM +0000, John Pilkington wrote:
> I'm thinking of installing one of these on a 'new' 32-bit laptop and
> would like to know what technical differences exist between their
> ATrpms builds. ISTR that years ago SL was built for systems with
> larger memory, but I haven't found anything that confirms this now.
> I suppose it must lurk in the spec files somewhere, but is there a
> handy explanation?

Scientific Linux (SL) and CentOS both strive to be as compatible as
possible to the upstream vendor distribution, RHEL.

As such they both refrain from changing anything not-trademark related
from the builds. Even when there is room for improvement both do not
change anything in the parts that are supposed to clone RHEL.

Both do have improved packages (like kernels with additional drivers)
in separate repositories.

I think it would not be difficult to make a switch from one
distribution to another w/o reinstalling. So I would just pick one and
install it.

As far as ATrpms' el<version> packages are concerned, they are built
against RHEL. As such they should work on RHEL, CentOS and Scientific
Linux just the same.

Traditionally CentOS is preferred by people looking for a generic
in-place replacement for RHEL, and Scientific Linux is preferred in
the high energy physics community and the communities in
contact. There were even discussions some time ago to merge the
efforts of the two teams.
--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-users


J.Pilk at tesco

Nov 25, 2011, 3:16 PM

Post #3 of 3 (290 views)
Permalink
Re: Choosing between sl6 and CentOS 6 [In reply to]

On 19/11/11 18:52, Axel Thimm wrote:
> On Sat, Nov 19, 2011 at 05:46:34PM +0000, John Pilkington wrote:
>> I'm thinking of installing one of these on a 'new' 32-bit laptop and
>> would like to know what technical differences exist between their
>> ATrpms builds. ISTR that years ago SL was built for systems with
>> larger memory, but I haven't found anything that confirms this now.
>> I suppose it must lurk in the spec files somewhere, but is there a
>> handy explanation?
>
> Scientific Linux (SL) and CentOS both strive to be as compatible as
> possible to the upstream vendor distribution, RHEL.
>
> As such they both refrain from changing anything not-trademark related
> from the builds. Even when there is room for improvement both do not
> change anything in the parts that are supposed to clone RHEL.
>
> Both do have improved packages (like kernels with additional drivers)
> in separate repositories.
>
> I think it would not be difficult to make a switch from one
> distribution to another w/o reinstalling. So I would just pick one and
> install it.
>
> As far as ATrpms' el<version> packages are concerned, they are built
> against RHEL. As such they should work on RHEL, CentOS and Scientific
> Linux just the same.
>
> Traditionally CentOS is preferred by people looking for a generic
> in-place replacement for RHEL, and Scientific Linux is preferred in
> the high energy physics community and the communities in
> contact. There were even discussions some time ago to merge the
> efforts of the two teams.

Thanks for the explanation, Axel. I've just installed SL6 from the DVD,
and KDE and most of MythTV from the web, but it was harder going than I
had expected and I ought to have read the mail archives more closely first.

In part my difficulties arose because I haven't often used yum; I find
smart more friendly and it makes it easier to install myth in stages.
yum refused to do anything after "yum install mythtv" because of
incompatibility of two manual pages in perl-XML-SAX and
perl-XML-SAX-Base. I haven't investigated what needs them.

The qt47 problem has been aired more than once, but I had gained the
impression that it could be fixed late in installation process. Not
true, or at least not without resorting to rpm -e nodeps to remove
qt-11. All the qt47 packages needed by myth should be installed
_before_ KDE and myth. And it wasn't initially obvious to me, from
reading the yum help, that I needed the quote marks, and not an
underscore or different capitalisation, in

yum groupinstall "KDE Desktop"

And then I had problems with smart; in the end quite simple, but
initially baffling. I couldn't get the channels to stick. It turned
out, IIRC, that "yum install yum-conf-atrpms" ( from the el6 repo) was
pointing to the x86_64 repo and that the alternative "yum install
atrpms-repo" (from atrpms-stable) was pointing to el6-i686 directories,
which don't exist. The ones that I need are el6-i386.

Now all is looking ok for me to start configuring my preferred
applications - and find out why it says my (intel) sound device isn't
working - shades of f12? :-)

Thanks for everything!

John P

_______________________________________________
atrpms-users mailing list
atrpms-users [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-users

atrpms users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.