Re: Multilib Middle-Ground

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux