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
