Multilib Middle-Ground

[Paul Howarth]

Andrew Farris wrote:
> Paul Howarth wrote:
>> Andrew Farris wrote:
>>> Kevin Kofler wrote:
>>>> Colin Walters <walters <at> verbum.org> writes:
>>>>> The right way to approach this I think is to target specific third
>>>>> party applications which we want to work out of the box.  Say for
>>>>> example, Flash and VMWare Workstation.  Surely there are others, but I
>>>>> think we can arrive at a reasonably sane set.  We then add these
>>>>> packages to the default install image.
>>>>
>>>> How about the empty set? We should only support properly-packaged 
>>>> RPMs, which will drag in these dependencies if they're installed 
>>>> (from a valid repository or using something like yum localinstall), 
>>>> if the proprietary applications don't want to provide them, why 
>>>> should we care?
>>>>
>>>> The KDE Live image is at the limit of CD size, every compat cruft 
>>>> package added is an application we have to remove to compensate for 
>>>> the size, why should we remove useful applications or go over the 
>>>> standard 700 MB CD size to accomodate proprietary crap which we 
>>>> can't ship and which isn't even packaged properly?
>>>
>>> Gross exaggeration... 'default install image' doesn't have to mean 
>>> Live CDs. Also are you actually suggesting that it would be best for 
>>> those proprietary applications to ship their own libraries because 
>>> Fedora makes it difficult to get their applications to work on x86_64 
>>> boxes due to the company being forced to figure out what i386 rpms 
>>> they have to explicitly require on those machines... in Fedora... and 
>>> not in other rpm based distros?  You've got to be kidding.
>>
>> $ rpm -qp --requires VMware-server-1.0.5-80187.i386.rpm
>> /bin/sh
>>
>> Does that look like a properly-package RPM to you? No soname deps 
>> whatsoever?
> 
> No, it doesn't, which is exactly my point... the harder, or more 
> explicitly, anything must be done to distribute proprietary software... 
> the more likely it will be done with a shell script which spews files 
> all over the place.
> 
> You don't get proprietary software to work nicely with package 
> management systems by making it even harder.  What I'm suggesting is 
> that finding a more inclusive solution to the multilib issue for those 
> applications that need it would be VALUABLE; I'm not suggesting its 
> necessary, or that it really is the free-software world's problem to fix 
> alone.  What Kevin seems to be saying is screw proprietary software let 
> it just not work... and thats just a bad plan.
> 
> Proprietary software SHOULD be shipped as cleanly as possible for the 
> target systems, but if that is difficult to do for the software 
> engineers at those companies, and its hard to maintain, then it WILL be 
> shipped with shell scripts and libraries all embedded in the 
> application.  It will be spewing files all over the place, causing 
> library conflicts, and ultimately making Fedora look bad, not the other 
> way around.
> 
> If the libraries are easy to get put in place, then the system libraries 
> might actually get used, and properly packaged proprietary software 
> might get distributed.  If the opposite is true for the libraries, then 
> can you even hope well packaged applications will be shipped from those 
> vendors?

VMware does use (mainly) system libraries but for some reason the 
dependencies on those libraries (by soname, not packagename) as created 
automatically by RPM are filtered out of the VMware package. If they had 
been left in, as they would be without what must be manual filtering, 
then yum would be able to pull in those libraries automatically.

I think we are all actually in violent agreement here, it's just that 
some proprietary vendors seem to go out of their way to defeat the 
dependency mechanisms that would help tools like yum install their software.

Paul.