[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Can I get Pan for CentOS 6.4
From: |
Duncan |
Subject: |
Re: [Pan-users] Can I get Pan for CentOS 6.4 |
Date: |
Sun, 3 Nov 2013 04:46:39 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 6e6fd84 /usr/src/portage/src/egit-src/pan2) |
Beartooth posted on Sat, 02 Nov 2013 18:01:18 +0000 as excerpted:
> On Fri, 01 Nov 2013 04:50:41 +0000, Duncan wrote:
>
>> Beartooth posted on Thu, 31 Oct 2013 18:32:55 +0000 as excerpted:
>>
>>> I've just installed 6.4 on an old T30 ThinkPad, and I'm in the midst
>>> of setting it up. Can I get an rpm of Pan somewhere? [....]
>
>> rpmfind is still around, and lists x86_64 pan-0.139 rpms
> That got me started (many thanks!) -- and more poking eventually
> got me to the fedoraproject site for epel and the rpmfusion repos.
... Which are beyond my (dated and limited) realm of knowledge in the rpm
domain, so I'll simply wish you luck... but am glad I could point you at
some place to begin, at least. =:^)
>> Presumably if you're still on 32-bit, you can change the arch
>> accordingly and get a working rpm, but be aware that with 32-bit some
>> distros will use i386, others i586 or i686, so you might want to search
>> for each or simply leave the arch blank (tho then you'll get ppc and
>> etc hits as well).
> Here you lose me. I understand 32 vs. 64 (I think); but what are
> the differences between i386, i586, and i686? How do I tell which I've
> got?
In a nutshell, the lower the leftmost digit, the earlier the generation
it covers, but they might be slightly less efficient on anything close to
modern hardware. i386 rpms use a more generic CPU instruction set that
should be compatible with all 32-bit x86 CPUs running Linux. i586 is the
Pentium generation and denotes use of CPU instructions not available on
pre-Pentium CPUs, so compatibility is lost with the oldest CPUs, but they
should be slightly more efficient on newer CPUs. i686 is Pentium-II/
PentiumPro, which is still /well/ before the turn of the century in terms
of 32-bit x86 CPUs, but in theory will be slightly more efficient again
in terms of use on anything even close to current generation x86.
However, because all three are now well in the past (and IIRC the Linux
kernel won't even run on i386 any more, it requires at least i486, and I
think I read somewhere that glibc requires i586 at least), all three of
the above should be usable on anything from this century and even back
into last century a bit, and for most packages (media codecs and encoders/
decoders being the best known exception), the efficiency gains of i686
over i386 are effectively marginal, so in practice it's a distinction
without a difference.
But, the distinction remains, mostly between various rpm-based distros,
with some of the "newer" (relative terms, we're talking last century
technology after all) distros standardizing on i686 packages as a matter
of policy, others continuing to use i386 because it /doesn't/ make that
much difference most of the time and that's what they started with, and
some splitting the difference and choosing i586.
So as my original mention hinted by suggesting that you look for all
three, it shouldn't matter much which you choose; it's mostly simply a
nuisance that you have to search for all of them in ordered to get a good
picture of the rpms available for 32-bit x86.
Which was one reason a lot of people were happy when amd64 aka x86_64
came out, as it was only a single name to search for once again (they
standardized on x86_64). So if you're running 64-bit x86, you don't have
to worry about it, x86_64 is it; it's only if you're still running 32-bit
that there's this nuisance issue to worry about when you do rpm searches,
and even then, if your distro happens to be one of the ones listed by
rpmfind, you can usually get away with just searching on whichever one of
the three it uses. Only when you need something not available for it do
you need to go looking at the others. =:^)
>> If you're willing to go with something earlier than pan-0.139 in
>> ordered to get more directly RHEL/CentOS compatible packages, I see
>> 0.135, 0.134 and 0.133 listed, DAG packages for Red Hat Linux el6,
>> which should be centos 6 compatible tho I don't know about the minor
>> release version (centos 6.4).
>
> I would be willing -- my kingdom for a Pan! -- but the
> fedoraproject for the rpmfusions *seems* designed to be exactly what I
> want. I have memories clear back to RH7 of dependency hells ....
Glad pan's such a priority for you. =:^)
Meanwhile, that was one of the benefits of switching to gentoo -- a lot
of that dependency hell stuff just went away, and where there were still
problems, it was *FAR* easier to just build it myself than it was back on
a binary-based distro, because gentoo is /based/ on building from source
so splitting up every lib into runtime and buildtime components like most
binary distros do (thus compounding the dependency hell issues) doesn't
make much sense, because needing those buildtime components is assumed in
the first place. =:^)
But while it was perfect for me and I'd suggest it for many, I don't
think it'd be a good match for you, as you already know and are
reasonably comfortable with the rules in rpm-based systems, and learning
gentoo would be a whole new ballgame for you.
>> Personally, I'd try the pan-0.139 fedora 18/19 packages first, as
>> they're current pan version and fedora being red hat family...
>
> With respect, that sounds like an open invitation to all the
> fiends of dependency-hell.
Well, I figured while there might be some of that, it'd likely be rather
more limited than if you tried an OpenSuSE rpm, for instance...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman