SCIENTIFIC-LINUX-USERS Archives

July 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Sun, 14 Jul 2013 08:48:48 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (131 lines)
On 07/14/2013 01:52 AM, John Pilkington wrote:
> On 14/07/13 07:19, Yasha Karant wrote:
>> On 07/13/2013 01:14 AM, John Pilkington wrote:
>>> On 13/07/13 08:15, Yasha Karant wrote:
>>>> On 07/12/2013 05:38 PM, Todd And Margo Chester wrote:
>>>>> On 07/12/2013 01:05 PM, Yasha Karant wrote:
>>>>>> The issue is that the application would not pass configure without
>>>>>> disabling these options.  I have tried the various pre-built RPMs for
>>>>>> vlc that have been mentioned, but all the ones that I have found have
>>>>>> dependencies that cause conflicts with other versions of the same
>>>>>> dependency (typically, some .so package).  Because the linux
>>>>>> application
>>>>>> environment is not polymorphic with encapsulation, one cannot have
>>>>>> both
>>>>>> versions of some such dependency installed.
>>>>>
>>>>> Hi Yasha,
>>>>>
>>>>>     It was a total pain in the butt the first few times
>>>>> through.  I had to do a lot of "rpm -e xxx" and waiting
>>>>> until yum would finally stop bitching.
>>>>>
>>>>>     I did get there eventually and haven't had a problem
>>>>> since.  Stick to it and you will get there too.
>>>>>
>>>>> -T
>>>>
>>>> Hi Todd,
>>>>
>>>> My understanding is that your procedure can result in system
>>>> instability
>>>> because of the lack of polymorphism and encapsulation.  If one uses
>>>> repositories other than those from SL6 or from those repositories that
>>>> claim the use thereof will not introduce stock (SL6x)
>>>> incompatibilities,
>>>> then getting an application that requires such incompatible RPMs may
>>>> cause problems.  The solution of erasing the conflicting RPM and
>>>> presumably loading a replacement RPM that is not part of the stock
>>>> compatible distribution can "break" other applications that are
>>>> dependent upon such RPMs.
>>>>
>>>> Building from a SRPM probably will not solve the problem because the
>>>> source RPM presumably requires the same RPMs (or SRPMs) that either do
>>>> not exist for stock SL6x or conflict with stock SL6x RPMs.  Again --
>>>> are
>>>> there any SL6x compatible source packages or installable RPMs that
>>>> supply the functionalities that I had to disable in building the
>>>> current
>>>> production vlc application from source?
>>>>
>>>> Yasha Karant
>>>>
>>> I have vlc 2.0.7 installed on my SL6 i686 laptop.  It's from rpmfusion,
>>> which has, I understand, stricter policies on compliance than ATrpms.  I
>>> don't know what, if any, restrictions were applied in the build, and I
>>> haven't tried it on many file formats, but it works well for me.  Have
>>> you tried/considered it?
>>>
>>> Perhaps I should add that I'm also using an elrepo kernel and
>>> kde-unstable.
>>>
>>> Here's the 64-bit version. extras, devel are there too.
>>>
>>> http://download1.rpmfusion.org/free/el/updates/testing/6/x86_64/vlc-2.0.7-1.el6.x86_64.rpm
>>>
>>>
>>>
>>>
>>> John P
>>
>> I installed the rpmfusion repository, found vlc 2.0.6, and allowed the
>> GUI add/remove software to proceed.  vlc 2.0.6 now is installed on my
>> IA-32 laptop; when I get to the office, I will proceed with the same for
>> X86-64.
>>
>> Are you aware if this vlc includes all needed codecs, some of which
>> evidently only can be installed from EU sources?
>>
>> Otherwise, the rpmfusion repository seems to provide all of the needed
>> dependencies.  (Note from the rpmfusion instructions:  You need to
>> enable EPEL on RHEL 5 & 6 or compatible distributions like CentOS before
>> you enable RPM Fusion for EL.)
>>
>> Thank you for the reference.
>>
>> Yasha Karant
>>
>
> I may be mistaken, but I think vlc uses its own codecs.  On my Fedora 17
> box there's  a folder /usr/lib64/vlc/plugins/codec/, installed from
> vlc-core.   See eg Yum-extender, Package Filelist.
>
> I thought you wanted 2.0.7?  Note that that is in the testing repo.
> Enabling that should give a mirrorlist.
>
> mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-testing-$releasever&arch=$basearch
>
>
> HTH
>
> John P

John,

Although vlc 2.0.7 is the current stable production release from vlc, it 
is not the same from the rpmfusion respository, for which 2.0.6 is 
stable.  I avoid (if at all possible) any "testing", pre-production, or 
beta releases on any production machine.  My experience has been that 
introducing a "testing" release from many of these repositories also 
gets "testing" versions of core libraries and other functionalities, 
some of which truly are not ready for "prime time" -- vlc 2.0.7 may be 
production, but some other library release version that is being used 
with the repository release, but which otherwise is not required for the 
application in question, also is so mandated but only by the repository.

Sometimes, functionality requires the installation of testing software 
on a production machine -- particularly if the "stable" release does not 
support some otherwise Microsoft-only hardware (the USA has found 
Microsoft to be a monopoly, but has forced no meaningful remedies, 
unlike the EU for which at least some parts of the monopoly have been 
broken through either enforced compatibility or reverse engineered "open 
systems" workarounds for which Microsoft effectively cannot sue the 
provider within the EU).

Thus, I stayed with 2.0.6 that (presumably) is a large improvement over 
the 1.x vlc I had been using.

Thanks again.

Yasha Karant

ATOM RSS1 RSS2