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@xxxxxxxxx> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
