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 04-30-2008, 05:44 PM
Warren Togami
 
Default Multilib Middle-Ground

seth vidal wrote:

On Wed, 2008-04-30 at 12:33 -0400, Warren Togami wrote:


This avoids the lose of:
- expecting the user to manually install a complicated set of
arch-specific packages because they can't use yum groupinstall



I think you're overestimating how many folks think this is a big deal.



Chinese users?
Indian users?

Is this really an overestimation?

Warren Togami
wtogami@redhat.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 05:47 PM
seth vidal
 
Default Multilib Middle-Ground

On Wed, 2008-04-30 at 13:44 -0400, Warren Togami wrote:
> seth vidal wrote:
> > On Wed, 2008-04-30 at 12:33 -0400, Warren Togami wrote:
> >
> >> This avoids the lose of:
> >> - expecting the user to manually install a complicated set of
> >> arch-specific packages because they can't use yum groupinstall
> >
> >
> > I think you're overestimating how many folks think this is a big deal.
> >
>
> Chinese users?
> Indian users?
>
> Is this really an overestimation?

but it's not ALL chinese or indian users.

it's a subset who happen to need i386 pkgs and who happen to have an
x86_64 box.

And then above that it's the subset of users who cannot figure out how
to cut and paste the command they need from a faq.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 05:59 PM
Warren Togami
 
Default Multilib Middle-Ground

seth vidal wrote:

On Wed, 2008-04-30 at 13:44 -0400, Warren Togami wrote:

seth vidal wrote:

On Wed, 2008-04-30 at 12:33 -0400, Warren Togami wrote:


This avoids the lose of:
- expecting the user to manually install a complicated set of
arch-specific packages because they can't use yum groupinstall


I think you're overestimating how many folks think this is a big deal.


Chinese users?
Indian users?

Is this really an overestimation?


but it's not ALL chinese or indian users.

it's a subset who happen to need i386 pkgs and who happen to have an
x86_64 box.

And then above that it's the subset of users who cannot figure out how
to cut and paste the command they need from a faq.

-sv


This is "making stuff just work" vs. "eliminate all i386".

We are a making a serious mistake here catering to the MINORITY of users
who want the latter.


Warren Togami
wtogami@redhat.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 06:04 PM
seth vidal
 
Default Multilib Middle-Ground

On Wed, 2008-04-30 at 13:59 -0400, Warren Togami wrote:
> seth vidal wrote:
> > On Wed, 2008-04-30 at 13:44 -0400, Warren Togami wrote:
> >> seth vidal wrote:
> >>> On Wed, 2008-04-30 at 12:33 -0400, Warren Togami wrote:
> >>>
> >>>> This avoids the lose of:
> >>>> - expecting the user to manually install a complicated set of
> >>>> arch-specific packages because they can't use yum groupinstall
> >>>
> >>> I think you're overestimating how many folks think this is a big deal.
> >>>
> >> Chinese users?
> >> Indian users?
> >>
> >> Is this really an overestimation?
> >
> > but it's not ALL chinese or indian users.
> >
> > it's a subset who happen to need i386 pkgs and who happen to have an
> > x86_64 box.
> >
> > And then above that it's the subset of users who cannot figure out how
> > to cut and paste the command they need from a faq.
> >
> > -sv
>
> This is "making stuff just work" vs. "eliminate all i386".
>
> We are a making a serious mistake here catering to the MINORITY of users
> who want the latter.

Warren,
Please cut the drama. You make it sound like we just decided to ignore
the icebergs. I really don't see it as that big of a deal. We currently
have no way of magically distinguishing pkgs where we do want the i386
and pkgs where we don't.

As Bill said - the whitelist is just pain to maintain. So, if we want
something like this then we make it a tag at the rpm level. Heck, you
can have it be a rather innocuous provides that we could hack into yum
to look for:

Provides: look-for-i386-too

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 06:18 PM
Jakub Jelinek
 
Default Multilib Middle-Ground

On Wed, Apr 30, 2008 at 02:04:07PM -0400, seth vidal wrote:
> As Bill said - the whitelist is just pain to maintain. So, if we want
> something like this then we make it a tag at the rpm level. Heck, you
> can have it be a rather innocuous provides that we could hack into yum
> to look for:
>
> Provides: look-for-i386-too

The i386 Gtk IM plugins wouldn't be used if gtk2.i386 isn't installed,
right? Similarly PAM i386 modules aren't needed when pam.i386 isn't
installed and NSS i386 modules when glibc.i[36]86 isn't installed.
In that case it would be best if this kind of dependency was somehow encoded
in the packages, rather than just forcing installation of unneeded i386
packages.

Jakub

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 06:22 PM
seth vidal
 
Default Multilib Middle-Ground

On Wed, 2008-04-30 at 14:18 -0400, Jakub Jelinek wrote:
> On Wed, Apr 30, 2008 at 02:04:07PM -0400, seth vidal wrote:
> > As Bill said - the whitelist is just pain to maintain. So, if we want
> > something like this then we make it a tag at the rpm level. Heck, you
> > can have it be a rather innocuous provides that we could hack into yum
> > to look for:
> >
> > Provides: look-for-i386-too
>
> The i386 Gtk IM plugins wouldn't be used if gtk2.i386 isn't installed,
> right? Similarly PAM i386 modules aren't needed when pam.i386 isn't
> installed and NSS i386 modules when glibc.i[36]86 isn't installed.
> In that case it would be best if this kind of dependency was somehow encoded
> in the packages, rather than just forcing installation of unneeded i386
> packages.

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.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 07:32 PM
Thomas M Steenholdt
 
Default Multilib Middle-Ground

seth vidal wrote:

On Wed, 2008-04-30 at 14:18 -0400, Jakub Jelinek wrote:

On Wed, Apr 30, 2008 at 02:04:07PM -0400, seth vidal wrote:

As Bill said - the whitelist is just pain to maintain. So, if we want
something like this then we make it a tag at the rpm level. Heck, you
can have it be a rather innocuous provides that we could hack into yum
to look for:

Provides: look-for-i386-too

The i386 Gtk IM plugins wouldn't be used if gtk2.i386 isn't installed,
right? Similarly PAM i386 modules aren't needed when pam.i386 isn't
installed and NSS i386 modules when glibc.i[36]86 isn't installed.
In that case it would be best if this kind of dependency was somehow encoded
in the packages, rather than just forcing installation of unneeded i386
packages.


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.

-sv




I agree with Seth on this one. Also, at first thought at least, it
should be possible to come up with the semantics to make this work, if
needed.


For one, I'm happy to loose the i386 stuff by default.

/Thomas

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 08:08 PM
Chris Snook
 
Default Multilib Middle-Ground

Warren Togami wrote:

Bill Nottingham wrote:

Warren Togami (wtogami@redhat.com) said:

* In the case of this scim change: You do a Korean language install.
Even on a non-LiveCD install you end up missing i386 (and font) packages
necessary for full Korean desktop support. There is no obvious way for
the user to know why it broke. It is suddenly impossible to have a full
Korean language desktop install by using the yum group. THIS IS A BIG
PROBLEM OUTSIDE OF LIVECD.


... 'and font'? The scim change changes fonts? O RLY?

This is *exactly* what I said. You're saying we should do something
special for an input method (for GTK only) that we don't do for QT
input methods, NSS modules, PAM modules, etc.


Then I guess we are really not that much worse off. It is impossible
for yum groupinstall to "fix" these problems in Fedora 9.


This points to a more general problem: We were not happy with having a
huge pile of unnecessary i386 packages so our solution was to completely
eliminate them from the default install. We went TOO FAR
overcompensating for the previous broken multilib behavior.


Dependencies or a comps multilib whitelist could be a nice
middle-ground. Some users want to be i386-free. Other users want a
tiny set of expected packages to be multilib to avoid confusion. The
current yum option is either all or none.


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". This way "yum groupinstall korean-support" can install
everything the user expects.


This avoids the lose of:
- expecting the user to manually install a complicated set of
arch-specific packages because they can't use yum groupinstall
- expecting the user to change the yum multilib priority option and
subject themselves to a huge pile of unnecessary crap that they will
never need.


No time to do this before F9.

Warren Togami
wtogami@redhat.com



Perhaps we need to think about packaging policies in a more associative way,
rather than a hierarchical way. The package groups make sense for a lot of
things, but they aren't very good at describing sets of packages, such as
libraries and devel packages, that span the entire distribution. I'd love to
see a screen with a half-dozen or so toggles early in the installer with
switches such as these:


[X] Install 32-bit libraries

This will increase the size of the installation and the time required to
download software updates, but will also make it more convenient to install
applications not included in Fedora. These libraries can also be installed
later using yum or PackageKit. If you are using a system with a slow internet
connection or a small hard drive, you may want to disable this.


[ ] Install development headers

This will increase the size of the installation and the time required to
download software updates, but will also make it more convenient to compile
applications from source code. These headers can also be installed later using
yum or PackageKit. If you plan to use the system for software development, it
may be convenient to enable this.


We could even have these switches affect the final yum configuration, perhaps
through selection of packages such as yum-basearchonly. The switch screen would
also be a good place to ask a few questions to distinguish between power users
and newbs, so we could improve general usability without interfering with the
way the developers and testers (our most important users) work. Obviously this
is not F9 stuff, but something to think about as we look to the future and think
about high-level usability.


-- Chris

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 08:27 PM
"Colin Walters"
 
Default Multilib Middle-Ground

On Wed, Apr 30, 2008 at 4:08 PM, Chris Snook <csnook@redhat.com> wrote:
>
> [X] Install 32-bit libraries

I think we want to move away from "Build your own Linux", rather than
closer; and these kinds of questions move us in the wrong direction.

There is a more general problem at work here - we want to provide
packages so that third party software can work, even though nothing
else in the install image depends on it. For example of how this
isn't just an x86_64 issue; some things out there require
compat-libstdc++, or at least they did in the recent past.

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.

> [ ] Install development headers

Hmm? I don't see what you want here that's not covered by the
combination of the "Development Tools" comps group as well as
yum-builddep.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 09:29 PM
"Jeff Spaleta"
 
Default Multilib Middle-Ground

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

-jef"how do you like my rabbit hole? cosy enough for you?"spaleta

--
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 12:33 PM.

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