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?

IDL
MatLab
LabView
Mathematica
SAS/IML and SAS/STAT
nag.com library products
any number of proprietary fortran and C compilers


Throw in Sun's 32 bit jvm's too.

Would it be possible to grow rpm meta-packages of 32-bit lib
dependencies for common applications as they become known with some
consistent name convention so something like

yum install vmware_32bit_libs
would fix things instead of having to know each needed file and which
package provides it?


Also, what's going to happen in an upgrade of a machine with existing 32
bit apps? Will the older libs stay? Will they work?


--
Les Mikesell
lesmikesell@gmail.com

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

On Wed, Apr 30, 2008 at 5:29 PM, Jeff Spaleta <jspaleta@gmail.com> 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?

I don't know - what deps do they need?

The top of the list though is the deps such that Adobe Flash works out
of the box. On i386 this would ensure we pull in libflashsupport. On
x86_64 we'd also need to pull in 32 bit libpulseaudio and some other
things, I believe?

Regardless, the point is that we need to actually make choices about
what's included in the desktop install, figuring out the tradeoffs,
rather than punting it to users with incomprehensible questions.

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

On Wed, Apr 30, 2008 at 3:28 PM, Colin Walters <walters@verbum.org> wrote:
> I don't know - what deps do they need?

Give me about $10k to purchase the full compliment of licenses and
I'll let you know :->

-jef

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

Les Mikesell wrote:

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?

IDL
MatLab
LabView
Mathematica
SAS/IML and SAS/STAT
nag.com library products
any number of proprietary fortran and C compilers


Throw in Sun's 32 bit jvm's too.

Would it be possible to grow rpm meta-packages of 32-bit lib
dependencies for common applications as they become known with some
consistent name convention so something like

yum install vmware_32bit_libs
would fix things instead of having to know each needed file and which
package provides it?




I don't see how this would be easier to maintain that the whitelist
solution. I think it would actually be a lot harder in the long run.


/Thomas

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

On Wed, 2008-04-30 at 19:28 -0400, Colin Walters wrote:
> On Wed, Apr 30, 2008 at 5:29 PM, Jeff Spaleta <jspaleta@gmail.com> 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?
>
> I don't know - what deps do they need?
>
> The top of the list though is the deps such that Adobe Flash works out
> of the box. On i386 this would ensure we pull in libflashsupport. On
> x86_64 we'd also need to pull in 32 bit libpulseaudio and some other
> things, I believe?

Well what should happen is flash is pulled from Adobe's own repo, and
since they're pulling from a repo anyway, yum should do what its
designed to do and pull in all the i386 deps flash needs in the same
transaction. There's no need for it to be in the default install or on
the install media, as far as flash is concerned.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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?

Kevin Kofler

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

Warren Togami <wtogami <at> redhat.com> writes:
> Perhaps we need a third option like "smart" which uses a multilib
> whitelist that can be updated via repodata. Anaconda and other GUI
> interfaces can allow the user to choose between "smart" and "100% i386
> free".

FYI, the KDE Live image for x86_64 is somewhere around 697 to 698 MB, even just
glibc.i686 will likely make it go over CD size!

Kevin Kofler

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

On Wed, 2008-04-30 at 14:22 -0400, seth vidal wrote:
>
> You'll note the default behavior in F9 is not install any i386 pkgs
> unless explicitly asked for (or as a dependency).
>
> If you want to have dependencies have arch-specific information in
> them then, again, we need to talk about that at the rpm layer.

I believe this has already been implemented in RPM.

https://bugzilla.redhat.com/show_bug.cgi?id=235755
http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commitdiff;h=48ff62a5291458ed1181cd6c 31dcadb193ad2f8e


--
dwmw2

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

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.


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

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?


Paul.

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