Multilib Middle-Ground

[Andrew Farris]

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?

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB  5BD5 5F89 8E1B 8300 BF29