FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-01-2008, 09:22 AM
Kevin Kofler
 
Default Multilib Middle-Ground

Andrew Farris <lordmorgul <at> gmail.com> writes:
> 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.

They're not forced to explicitly require anything, just not explicitly turn off
the RPM feature which AUTOMATICALLY adds those Requires, in a way which:
* is only fulfilled by the correct architecture package of the dependency,
because RPM uses libfoo.so.1 for 32-bit and libfoo.so.1()(64bit) for 64-bit
dependencies,
* works fully across (RPM-based) distributions, because it doesn't require a
particular package name, but an soname. And the application won't run anyway if
you don't have a library with that soname (which is the whole reason why
compat-libstdc++ is needed), so if one distro has libfoo.so.1 and another has
libfoo.so.2, omitting the automatic dependencies won't solve the problem, it
will just make the application error at runtime rather than at install-time
(which sucks, why wait until runtime to report a problem which can be detected
during installation?).

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 09:34 AM
Andrew Farris
 
Default Multilib Middle-Ground

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@gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 10:09 AM
"Bill Crawford"
 
Default Multilib Middle-Ground

On 01/05/2008, Andrew Farris <lordmorgul@gmail.com> wrote:

> 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?

They are deliberately bypassing the mechanisms to make that possible.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 10:12 AM
Paul Howarth
 
Default Multilib Middle-Ground

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 11:05 AM
Kostas Georgiou
 
Default Multilib Middle-Ground

On Wed, Apr 30, 2008 at 01:29:40PM -0800, Jeff Spaleta wrote:

> On Wed, Apr 30, 2008 at 12:27 PM, Colin Walters <walters@verbum.org> wrote:
> > 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.
>
> Would you include the following in your "sane" set?
>

> MatLab
> Mathematica
> nag.com library products

There are 64bit versions of both so there is no need to install the
32bit vesrions.

> any number of proprietary fortran and C compilers

Most of them will also have 64bit versions as well.

> IDL
> LabView
> SAS/IML and SAS/STAT

No idea but I will not be surprised if 64bit versions are available for
them as well.

Most often than not they don't run out of the box in fedora without some
playing around anyway (you have to label some libs textrel_shlib_t,
provide links for things like /usr/share/X11/rgb.txt because they ship
their own version of libX11 which expects files under /usr/X11R6 etc.)

Kostas

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 12:16 PM
"Josef Bacik"
 
Default Multilib Middle-Ground

Gmail makes it hard for me to follow long threads, so sorry if this
response is a little out of place. What exactly is the purpose of
installing 32bit binaries on a 64bit box? The only things I've been
able to see in this thread is for installing proprietary applications.
So we as the Fedora community, who are strongly dedicated to being
open and free, are going to great lengths in order to make sure that
we can better use proprietary applications/formats? Every time I do
an install on one of my boxes I have to run my little "get rid of all
the 32 bit rpms" script, otherwise I end up with weird dependancy hell
problems. Granted the dependancy hell problems are usually my own
doing by running some rawhide packages and such, but nevertheless the
problems do not occur with just x86_64/noarch packages.

I do not use flash, because I believe in what are supposedly the core
values of Fedora. I do not use any proprietary software, because I
believe in freedom and openness. Albeit there are plenty of users who
do not share my views, I think that punishing us that do believe in
everything that Fedora is supposed to be about should not be having to
go out of their way in order to put their system back into a normal
state. I think that if you wish to install proprietary software on
your system, you should be the one who has to do clicky clicky in
order to make it work, and not I who has to run this crappy script
just to have a clean x86_64 install.

I believe having anything but the default be non-multilib is sending
the wrong kind of message, and is border line hypocritical. Add an
option so that people can have the multilib stuff installed works, but
forcing everybody to have twice the number of packages installed is a
poor answer.

Josef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 12:52 PM
Les Mikesell
 
Default Multilib Middle-Ground

Paul Howarth wrote:
>
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.


Have you looked at what packages have to include to install on more
than one linux distro/version? And fedora is the worst of the bunch in
terms of not being compatible with last week's version of itself. Give
the 3rd party packagers a target before you complain about them missing it.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 12:57 PM
Paul Howarth
 
Default Multilib Middle-Ground

Les Mikesell wrote:

Paul Howarth wrote:
> 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.


Have you looked at what packages have to include to install on more
than one linux distro/version? And fedora is the worst of the bunch in
terms of not being compatible with last week's version of itself. Give
the 3rd party packagers a target before you complain about them missing it.


As Kevin mentioned earlier in this thread, the soname dependencies that
RPM adds automatically are *real* dependencies and I'm not aware of any
RPM-based distribution that doesn't use them. So what's the point of
stripping them out?


Stripping of pathname-based and package-name based dependencies I can
understand, but not the library deps.


Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 12:58 PM
Les Mikesell
 
Default Multilib Middle-Ground

Bill Crawford wrote:

On 01/05/2008, Andrew Farris <lordmorgul@gmail.com> wrote:


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?


They are deliberately bypassing the mechanisms to make that possible.


What's the standard mechanism to do this across rpm-using distributions
and version?


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 01:13 PM
Les Mikesell
 
Default Multilib Middle-Ground

Andrew Farris wrote:


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.


Would you mind leaving the 'p' word out of this discussion? The same
principle applies to all software that isn't recompiled and repackaged
between every version, including the user's own and other programs where
source is available but you don't want to have to rebuild (if we did
want to recompile every week we'd be running gentoo...). Pretending
this is specific to proprietary software puts the wrong spin on the
conversation here. The only difference being proprietary makes in this
case is that someone else needs to do this work and probably maintain
specific versions separately for each fedora version instead of every
using doing that himself.


--
Les Mikesell
lesmikesell@gmail.com

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

Thread Tools




All times are GMT. The time now is 10:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org