3:50 a.m.
So I nonchalantly typed this and walked away from my rawhide box..
"yum -y install libgnome-devel gcc-c++"
I must admit to being somewhat surprised at this :
Dependencies Resolved
=============================================================================
Package Arch Version Repository
Size
=============================================================================
Installing:
gcc-c++ x86_64 4.1.1-14 development
3.6 M
libgnome-devel i386 2.15.1-3.fc6 development
112 k
libgnome-devel x86_64 2.15.1-3.fc6 development
117 k
Installing for dependencies:
GConf2 i386 2.14.0-2.1 development
1.5 M
GConf2-devel x86_64 2.14.0-2.1 development
202 k
ORBit2 i386 2.14.2-1.fc6 development
252 k
ORBit2-devel x86_64 2.14.2-1.fc6 development
386 k
alsa-lib-devel x86_64 1.0.12-1.rc1 development
1.4 M
atk i386 1.12.1-2 development
217 k
audiofile-devel x86_64 1:0.2.6-5 development
15 k
audit-libs i386 1.2.5-6 development
39 k
avahi i386 0.6.11-2.fc6 development
226 k
avahi-glib i386 0.6.11-2.fc6 development
13 k
bzip2-libs i386 1.0.3-3 development
36 k
cairo i386 1.2.0-2 development
451 k
cups-libs i386 1:1.2.2-7 development
175 k
dbus i386 0.90-8 development
638 k
dbus-devel x86_64 0.90-8 development
30 k
dbus-glib i386 0.70-4 development
153 k
dbus-glib-devel x86_64 0.70-4 development
10 k
esound-devel x86_64 1:0.2.36-3 development
34 k
fontconfig i386 2.3.95-6 development
190 k
gamin i386 0.1.7-1.2.2 development
119 k
gcc x86_64 4.1.1-14 development
4.7 M
glib2 i386 2.12.1-1 development
667 k
glib2-devel x86_64 2.12.1-1 development
1.3 M
glibc-devel x86_64 2.4.90-17 development
2.4 M
glibc-headers x86_64 2.4.90-17 development
589 k
gnome-vfs2 i386 2.15.90-2.fc6 development
1.3 M
gnome-vfs2-devel x86_64 2.15.90-2.fc6 development
486 k
gnutls i386 1.4.1-1 development
350 k
gtk2 i386 2.10.1-1 development
5.9 M
hal i386 0.5.7.1-2.fc6 development
287 k
hal-devel x86_64 0.5.7.1-2.fc6 development
157 k
indent x86_64 2.2.9-14.fc6 development
97 k
libIDL i386 0.8.7-1.fc6 development
85 k
libIDL-devel x86_64 0.8.7-1.fc6 development
18 k
libXcursor i386 1.1.7-1.1 development
32 k
libXfixes i386 4.0.1-2.1 development
14 k
libXft i386 2.1.10-1.1 development
44 k
libXinerama i386 1.0.1-2.1 development
9.9 k
libXrandr i386 1.1.1-3.1 development
15 k
libXrender i386 0.9.1-3.1 development
27 k
libacl i386 2.2.39-1.1 development
19 k
libattr i386 2.4.32-1.1 development
12 k
libbonobo i386 2.15.0-2 development
496 k
libbonobo-devel x86_64 2.15.0-2 development
500 k
libcap i386 1.10-25 development
22 k
libgcrypt-devel x86_64 1.2.2-3.1 development
266 k
libgnome i386 2.15.1-3.fc6 development
854 k
libgomp x86_64 4.1.1-14 development
54 k
libgpg-error-devel x86_64 1.3-3.1 development
16 k
libpng i386 2:1.2.10-6 development
242 k
libstdc++-devel x86_64 4.1.1-14 development
10 M
libxml2-devel x86_64 2.6.26-2.1.1 development
2.2 M
libxslt-devel x86_64 1.1.17-1.1 development
307 k
pango i386 1.13.5-1 development
334 k
zlib-devel x86_64 1.2.3-3 development
102 k
Updating for dependencies:
libstdc++ x86_64 4.1.1-14 development
330 k
Transaction Summary
=============================================================================
Install 58 Package(s)
Update 1 Package(s)
Remove 0 Package(s)
If the mix of 58 i386/64 packages is perfectly normal and required for
libgnome-devel then I'll go back to my corner and be quiet.
It failed the transaction check as well for the curious :
Transaction Check Error:
file /etc/gconf/schemas/desktop_default_applications.schemas from
install of gnome-vfs2-2.15.90-2.fc6 conflicts with file from package
gnome-vfs2-2.15.3-7
file /etc/gconf/schemas/desktop_gnome_url_handlers.schemas from
install of gnome-vfs2-2.15.90-2.fc6 conflicts with file from package
gnome-vfs2-2.15.3-7
file /etc/gconf/schemas/system_dns_sd.schemas from install of
gnome-vfs2-2.15.90-2.fc6 conflicts with file from package
gnome-vfs2-2.15.3-7
file /etc/gconf/schemas/system_http_proxy.schemas from install of
gnome-vfs2-2.15.90-2.fc6 conflicts with file from package
gnome-vfs2-2.15.3-7
file /etc/gconf/schemas/system_smb.schemas from install of
gnome-vfs2-2.15.90-2.fc6 conflicts with file from package
gnome-vfs2-2.15.3-7
But then gnome-vfs2 updated fine..
Transaction Test Succeeded
Running Transaction
Updating : gnome-vfs2 #########################
[1/4]
Updating : gnome-vfs2-smb #########################
[2/4]
Cleanup : gnome-vfs2-smb #########################
[3/4]
Cleanup : gnome-vfs2 #########################
[4/4]
Updated: gnome-vfs2.x86_64 0:2.15.90-2.fc6
Dependency Updated: gnome-vfs2-smb.x86_64 0:2.15.90-2.fc6
Complete!
And after that the devel packages installed fine, which was nice, but
odd I thought.
11:11 a.m.
Rahul wrote :
Naoki wrote:
> So I nonchalantly typed this and walked away from my rawhide box..
>
> "yum -y install libgnome-devel gcc-c++"
>
libgnome-devel pulls in a lot of deps. Thats normal.
Yeah, but he probably wanted to do :
yum -y install libgnome-devel.x86_64 gcc-c++.x86_64
I don't like the yum "feature" of installing all available archs of a
same package when it's explicitly requested either...
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2530.fc6
Load : 1.33 1.21 1.19
12:47 p.m.
On Wed, 2006-08-09 at 18:11 +0200, Matthias Saou wrote:
Rahul wrote :
> Naoki wrote:
> > So I nonchalantly typed this and walked away from my rawhide box..
> >
> > "yum -y install libgnome-devel gcc-c++"
> >
>
> libgnome-devel pulls in a lot of deps. Thats normal.
Yeah, but he probably wanted to do :
yum -y install libgnome-devel.x86_64 gcc-c++.x86_64
I don't like the yum "feature" of installing all available archs of a
same package when it's explicitly requested either...
If you have a patch that nicely deals with:
yum install libgnome\*
and guesses if the user meant: install libgnome*.x86_64 or
install libgnome.*(all archs)
send it to me, I'm amenable to that sort of thing.
-sv
1:05 p.m.
On Wed, Aug 09, 2006 at 01:47:57PM -0400, seth vidal wrote:
If you have a patch that nicely deals with:
yum install libgnome\*
and guesses if the user meant: install libgnome*.x86_64 or
install libgnome.*(all archs)
send it to me, I'm amenable to that sort of thing.
Can we just define and document it as being the former?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:12 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
On Wed, Aug 09, 2006 at 01:47:57PM -0400, seth vidal wrote:
> If you have a patch that nicely deals with:
>
> yum install libgnome\*
>
> and guesses if the user meant: install libgnome*.x86_64 or
> install libgnome.*(all archs)
>
> send it to me, I'm amenable to that sort of thing.
Can we just define and document it as being the former?
And what if they thought .* was a regexp and not globbing? :)
Bill
1:18 p.m.
On Wed, Aug 09, 2006 at 02:12:05PM -0400, Bill Nottingham wrote:
> > yum install libgnome\*
> > and guesses if the user meant: install libgnome*.x86_64 or
> > install libgnome.*(all archs)
> > send it to me, I'm amenable to that sort of thing.
> Can we just define and document it as being the former?
And what if they thought .* was a regexp and not globbing? :)
No problem! This issue is already documented!
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:53 p.m.
Matthew Miller wrote :
On Wed, Aug 09, 2006 at 02:12:05PM -0400, Bill Nottingham wrote:
> > > yum install libgnome\*
> > > and guesses if the user meant: install libgnome*.x86_64 or
> > > install libgnome.*(all archs)
> > > send it to me, I'm amenable to that sort of thing.
> > Can we just define and document it as being the former?
> And what if they thought .* was a regexp and not globbing? :)
No problem! This issue is already documented!
Yup.
I was just saying that I didn't like that "feature", not that I knew
better nor knew how to properly fix it.
I better not say that I don't like multilib, then, right? :-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2532.fc6
Load : 0.73 0.57 0.59
7:23 p.m.
Matthias Saou (thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
I was just saying that I didn't like that "feature",
not that I knew
better nor knew how to properly fix it.
I better not say that I don't like multilib, then, right? :-)
Obviously, to have things work right, x86_64 should be subscribed to both
the i386 and x86_64 extras repositories.
Bill
9:33 p.m.
On Wed, 2006-08-09 at 20:53 +0200, Matthias Saou wrote:
Matthew Miller wrote :
> On Wed, Aug 09, 2006 at 02:12:05PM -0400, Bill Nottingham wrote:
> > > > yum install libgnome\*
> > > > and guesses if the user meant: install libgnome*.x86_64 or
> > > > install libgnome.*(all archs)
> > > > send it to me, I'm amenable to that sort of thing.
> > > Can we just define and document it as being the former?
> > And what if they thought .* was a regexp and not globbing? :)
>
> No problem! This issue is already documented!
Yup.
I was just saying that I didn't like that "feature", not that I knew
better nor knew how to properly fix it.
I better not say that I don't like multilib, then, right? :-)
I have strong, negative feelings toward multilib myself but I understand
why it is there and needs to be there, sadly.
-sv
9:34 p.m.
On Wed, 2006-08-09 at 20:53 +0200, Matthias Saou wrote:
Matthew Miller wrote :
> On Wed, Aug 09, 2006 at 02:12:05PM -0400, Bill Nottingham wrote:
> > > > yum install libgnome\*
> > > > and guesses if the user meant: install libgnome*.x86_64 or
> > > > install libgnome.*(all archs)
> > > > send it to me, I'm amenable to that sort of thing.
> > > Can we just define and document it as being the former?
> > And what if they thought .* was a regexp and not globbing? :)
>
> No problem! This issue is already documented!
Yup.
I was just saying that I didn't like that "feature", not that I knew
better nor knew how to properly fix it.
one more item.
if you have no need for multilib then you can solve all of these
problems by doing:
exclude=*.?86
in your yum.conf
-sv
9:36 p.m.
On Wed, 2006-08-09 at 14:05 -0400, Matthew Miller wrote:
On Wed, Aug 09, 2006 at 01:47:57PM -0400, seth vidal wrote:
> If you have a patch that nicely deals with:
>
> yum install libgnome\*
>
> and guesses if the user meant: install libgnome*.x86_64 or
> install libgnome.*(all archs)
>
> send it to me, I'm amenable to that sort of thing.
Can we just define and document it as being the former?
so let's say we do that.
and then the person wants to install all packages named:
foo*.i?86
what should yum do in that case?
-sv
9:32 a.m.
On Wed, Aug 09, 2006 at 10:36:18PM -0400, seth vidal wrote:
> > send it to me, I'm amenable to that sort of thing.
> Can we just define and document it as being the former?
so let's say we do that.
and then the person wants to install all packages named:
foo*.i?86
what should yum do in that case?
Presumably, install all packages with names starting with foo for either
i386 or i686 (or i586) architecture.
Are you concerned that there might be a package
"foobarin86-5.3-1.fc6.x86_64"?
I guess "." is kind of an unfortunate separator for arch.....
But I'm still in favor of simply documenting what might happen in corner
cases and making the default case be something other than "multilib
pile-on!"
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:02 a.m.
On Thu, Aug 10, 2006 at 04:48:41PM +0200, Ralf Ertzinger wrote:
> Are you concerned that there might be a package
> "foobarin86-5.3-1.fc6.x86_64"?
> I guess "." is kind of an unfortunate separator for arch.....
That depends whether that's a shell glob or a regexp :)
The pattern is already defined as being a shell glob.
Seth, gimmie a hint. What's the issue you're worried about here? :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:04 a.m.
On Thu, 2006-08-10 at 11:02 -0400, Matthew Miller wrote:
On Thu, Aug 10, 2006 at 04:48:41PM +0200, Ralf Ertzinger wrote:
> > Are you concerned that there might be a package
> > "foobarin86-5.3-1.fc6.x86_64"?
> > I guess "." is kind of an unfortunate separator for arch.....
> That depends whether that's a shell glob or a regexp :)
The pattern is already defined as being a shell glob.
Seth, gimmie a hint. What's the issue you're worried about here? :)
I'm worried about someone legitimately wanting to install both arches
being stymied by this "feature".
-sv
10:33 a.m.
On Thu, Aug 10, 2006 at 11:04:18AM -0400, seth vidal wrote:
> > That depends whether that's a shell glob or a regexp
:)
> The pattern is already defined as being a shell glob.
> Seth, gimmie a hint. What's the issue you're worried about here? :)
I'm worried about someone legitimately wanting to install both arches
being stymied by this "feature".
Stymied, or required to do a bit of extra typing? 'Cause I'm pretty sure the
case where you want to install both archs *should* be the one where extra
typing is required. So, "yum install foo.*" (shades of DOS). Or, if it needs
to be "yum install foo.x86_64 foo.i386" (or "foo foo.i386"), is that
really
so bad?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:41 a.m.
On Thursday 10 August 2006 11:33, Matthew Miller wrote:
Stymied, or required to do a bit of extra typing? 'Cause I'm
pretty sure
the case where you want to install both archs *should* be the one where
extra typing is required. So, "yum install foo.*" (shades of DOS). Or, if
it needs to be "yum install foo.x86_64 foo.i386" (or "foo foo.i386"),
is
that really so bad?
it is when we want to provide a multilib environment when folks shouldn't have
to think about it. Our users should have to jump through hoops when they
want to run some 32bit app. It should Just Work. That's IMHO a big reason
why we are installing both arches by default. The folks that really CARE
about being pure lib are the ones that would have the ability to fiddle with
some bits in a yumconf file.
--
Jesse Keating
Release Engineer: Fedora
10:51 a.m.
Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
it is when we want to provide a multilib environment when folks
shouldn't have
to think about it. Our users should have to jump through hoops when they
want to run some 32bit app.
If someone installs a 32bit app via yum, it would automatically pull in
the necessary dependencies (wouldn't it?). If someone is installing
non-RPM software without yum, they'll have to be doing things manually
anyway (and could specify the arch).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:48 p.m.
On Thu, 2006-08-10 at 11:41 -0400, Jesse Keating wrote:
On Thursday 10 August 2006 11:33, Matthew Miller wrote:
> Stymied, or required to do a bit of extra typing? 'Cause I'm pretty sure
> the case where you want to install both archs *should* be the one where
> extra typing is required. So, "yum install foo.*" (shades of DOS). Or, if
> it needs to be "yum install foo.x86_64 foo.i386" (or "foo
foo.i386"), is
> that really so bad?
it is when we want to provide a multilib environment when folks shouldn't have
to think about it. Our users should have to jump through hoops when they
want to run some 32bit app. It should Just Work. That's IMHO a big reason
why we are installing both arches by default. The folks that really CARE
about being pure lib are the ones that would have the ability to fiddle with
some bits in a yumconf file.
So why aren't we doing "everything" installs by default because somebody
might have a piece of software that doesn't "just work" otherwise? I
just don't buy that argument.
Yum is perfectly capable of pulling in just the 32bit version of a
library if you install a 32bit package. If we're talking about tarballs
with binaries within.. all bets are off anyway, although it wouldn't be
hard to write a script to resolve and install the needed libs of
binaries in /opt/somesoftware path.
No, I don't like the behavior of installing both arches by default. :)
- Panu -
1:51 p.m.
On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
No, I don't like the behavior of installing both arches by
default.
I don't personally either, but I have the capacity to fix that for my system.
I'm just repeating the reasoning that was given to me the last time I bitched
about it.
--
Jesse Keating
Release Engineer: Fedora
1:56 p.m.
On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> No, I don't like the behavior of installing both arches by default.
I don't personally either, but I have the capacity to fix that for my system.
I'm just repeating the reasoning that was given to me the last time I bitched
about it.
So everyone hates it? anyone in favor?
-sv
1:59 p.m.
Le jeudi 10 août 2006 à 14:56 -0400, seth vidal a écrit :
On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > No, I don't like the behavior of installing both arches by default.
>
> I don't personally either, but I have the capacity to fix that for my system.
> I'm just repeating the reasoning that was given to me the last time I bitched
> about it.
So everyone hates it? anyone in favor?
We hate it :)
--
Nicolas Mailhot
2:04 p.m.
On Thu, 2006-08-10 at 20:59 +0200, Nicolas Mailhot wrote:
Le jeudi 10 août 2006 à 14:56 -0400, seth vidal a écrit :
> On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> > On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > > No, I don't like the behavior of installing both arches by default.
> >
> > I don't personally either, but I have the capacity to fix that for my
system.
> > I'm just repeating the reasoning that was given to me the last time I
bitched
> > about it.
>
> So everyone hates it? anyone in favor?
We hate it :)
okay - then here are a couple of more situations I want to make sure are
understood:
yum remove foo*
it should remove all packages starting with foo of EVERY arch or just of
the primary arch in the biarch set?
yum update foo*
ditto of above? What should it default to act on
b/c if:
yum install foo*
only installs the primary arch - not the secondary one - then we're
creating some expectation of it for the others.
consistency is a good thing, I think.
-sv
2:23 p.m.
Le jeudi 10 août 2006 à 15:04 -0400, seth vidal a écrit :
On Thu, 2006-08-10 at 20:59 +0200, Nicolas Mailhot wrote:
> Le jeudi 10 août 2006 à 14:56 -0400, seth vidal a écrit :
> > On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> > > On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > > > No, I don't like the behavior of installing both arches by
default.
> > >
> > > I don't personally either, but I have the capacity to fix that for my
system.
> > > I'm just repeating the reasoning that was given to me the last time I
bitched
> > > about it.
> >
> > So everyone hates it? anyone in favor?
>
> We hate it :)
>
okay - then here are a couple of more situations I want to make sure are
understood:
Ok, my own non-representative opinion there is :
1. yum operations should always target the primary arch when packages
are not already installed, and all installed arches otherwise
2. using globs for arches in the package list is silly - most of the
times if you target one or all arches it's the same rule for all the
packages. So the arch mode should not be specified in the package list
but via a specific yum flag ( --arch foo, --biarch, whatever)
3. control freaks which want a package-level arch granularity in the
orders they issue through yum can type full arches instead of globs.
This is not the general case and we should not optimize for it.
Regards,
--
Nicolas Mailhot
2:29 p.m.
Le jeudi 10 août 2006 à 21:23 +0200, Nicolas Mailhot a écrit :
3. control freaks which want a package-level arch granularity in the
orders they issue through yum can type full arches instead of globs.
This is not the general case and we should not optimize for it.
(if you want to save users some typing having an exclude shortcut or
list mode would help)
--
Nicolas Mailhot
2:34 p.m.
On Thu, Aug 10, 2006 at 03:04:07PM -0400, seth vidal wrote:
okay - then here are a couple of more situations I want to make sure
are
understood:
yum remove foo*
it should remove all packages starting with foo of EVERY arch or just of
the primary arch in the biarch set?
I would expect matches of all archs to be removed.
only installs the primary arch - not the secondary one - then
we're
creating some expectation of it for the others.
Actaully, there is precedent for somewhat equivalent behavior in yum
already. If you ask for a package by name without a version, "yum install"
will just give you the latest one -- but "yum remove" will take out all
matches.
consistency is a good thing, I think.
Bah. Hobgoblins and all that. :)
But really, given the above, I don't think it is inconsistent.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:35 p.m.
On Thu, 2006-08-10 at 15:34 -0400, Matthew Miller wrote:
On Thu, Aug 10, 2006 at 03:04:07PM -0400, seth vidal wrote:
> okay - then here are a couple of more situations I want to make sure are
> understood:
> yum remove foo*
> it should remove all packages starting with foo of EVERY arch or just of
> the primary arch in the biarch set?
I would expect matches of all archs to be removed.
> only installs the primary arch - not the secondary one - then we're
> creating some expectation of it for the others.
Actaully, there is precedent for somewhat equivalent behavior in yum
already. If you ask for a package by name without a version, "yum install"
will just give you the latest one -- but "yum remove" will take out all
matches.
> consistency is a good thing, I think.
Bah. Hobgoblins and all that. :)
But really, given the above, I don't think it is inconsistent.
In the situations where you dislike the current behavior - could you
just add: exclude=*.i?86
to your /etc/yum.conf and be done w/it?
-sv
3:43 p.m.
On Thu, Aug 10, 2006 at 04:35:57PM -0400, seth vidal wrote:
> But really, given the above, I don't think it is
inconsistent.
In the situations where you dislike the current behavior - could you
just add: exclude=*.i?86
to your /etc/yum.conf and be done w/it?
Doesn't that prevent i?86 packages from being pulled in by the depsolver
when actually needed?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
4:16 p.m.
On Thu, 2006-08-10 at 16:43 -0400, Matthew Miller wrote:
On Thu, Aug 10, 2006 at 04:35:57PM -0400, seth vidal wrote:
> > But really, given the above, I don't think it is inconsistent.
> In the situations where you dislike the current behavior - could you
> just add: exclude=*.i?86
> to your /etc/yum.conf and be done w/it?
Doesn't that prevent i?86 packages from being pulled in by the depsolver
when actually needed?
if you have none installed, why would you ever need them?
-sv
4:23 p.m.
On Thu, Aug 10, 2006 at 05:16:40PM -0400, seth vidal wrote:
> On Thu, Aug 10, 2006 at 04:35:57PM -0400, seth vidal wrote:
> > > But really, given the above, I don't think it is inconsistent.
> > In the situations where you dislike the current behavior - could you
> > just add: exclude=*.i?86
> > to your /etc/yum.conf and be done w/it?
> Doesn't that prevent i?86 packages from being pulled in by the depsolver
> when actually needed?
if you have none installed, why would you ever need them?
I'm not (necessarily) trying to have an all-64-bit system. I just don't want
compat-arch packages to be added to the system when they're not required by
something or asked for explicitly. I don't think that's unreasonable.
Otherwise, as someone mentioned, why *not* just do an Everything install?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:01 p.m.
seth vidal (skvidal(a)linux.duke.edu) said:
okay - then here are a couple of more situations I want to make sure
are
understood:
yum remove foo*
it should remove all packages starting with foo of EVERY arch or just of
the primary arch in the biarch set?
The problem is, logically, this should be all arches...
yum update foo*
and this *needs* to be all installed arches, or your transaction
will break.
Bill
5:33 p.m.
On Thu, 2006-08-10 at 15:04 -0400, seth vidal wrote:
okay - then here are a couple of more situations I want to make sure
are
understood:
yum remove foo*
it should remove all packages starting with foo of EVERY arch or just of
the primary arch in the biarch set?
yum update foo*
ditto of above? What should it default to act on
This is interesting. In my mind I've been thinking of globs as broken
because they pull in everything. Then I start using them when I remove
something and it works as I expect! Woohoo! Next time I use it to
install something and it's still "broken"....
Now that we've had this discussion I realize this isn't broken but a
design decision. But even though I now realize it is consistent, I
still think it is unexpected.
Here's why:
yum install vim*
installs vim-common.x86_64 vim-enhanced.x86_64 vim-minimal.x86_64
yum install xfsprogs*
installs xfsprogs.x86_64 xfsprogs.i386 xfsprogs-devel.x86_64
xfsprogs-devel.i386
Why should xfsprogs install i386 packages when vim doesn't?
-Toshio
5:51 p.m.
Toshio Kuratomi wrote:
On Thu, 2006-08-10 at 15:04 -0400, seth vidal wrote:
>okay - then here are a couple of more situations I want to make sure are
>understood:
>
>yum remove foo*
>
>it should remove all packages starting with foo of EVERY arch or just of
>the primary arch in the biarch set?
>
>yum update foo*
>
>ditto of above? What should it default to act on
>
>
This is interesting. In my mind I've been thinking of globs as broken
because they pull in everything. Then I start using them when I remove
something and it works as I expect! Woohoo! Next time I use it to
install something and it's still "broken"....
Now that we've had this discussion I realize this isn't broken but a
design decision. But even though I now realize it is consistent, I
still think it is unexpected.
Here's why:
yum install vim*
installs vim-common.x86_64 vim-enhanced.x86_64 vim-minimal.x86_64
yum install xfsprogs*
installs xfsprogs.x86_64 xfsprogs.i386 xfsprogs-devel.x86_64
xfsprogs-devel.i386
Why should xfsprogs install i386 packages when vim doesn't?
-Toshio
Just a suspicion. And a suggestion, perhaps something for the FAQ.
It seems to me that
yum install foo*
is a command line. If typed to the bash interpretter, bash will
notice the "*" in foo and attempt filename expansion.
If there happens to be some files named, say, foo1, foo2, foo3 in
the current directory, then typing
yum install foo*
will be expanded by bash into
yum install foo1 foo2 foo3
which will likely result in the error messages about foo1, foo2, and
foo3 being nonexistent packages.
If, on the other hand, there are no files starting with foo in the
current directory, then foo* will be passed to yum, resulting
effectively in the command
yum install foo*
and yum will hae an opportunity to expand the wildcard.
This variation in behaviour of a command, depending on the contents
of the current directory, has often confused students here; and
often baffled the instructor (me) until it occurred to me to ask
what was in the current directory. ;0(
It seems to me, in the interest of not misleading the uninitiated to
the intricacies of bash (particularly if we are recruiting users
from M$s products which always hand the wildcards to the applications)
we might promote typing things like this as
yum install 'foo*'
to make sure that the wildcard gets to yum, if I understand correctly
that it expands the "*" using rpm names (not filenames in the current
directory, as bash will do).
I hope that the above suggestion is clearly stated. My explanations
are not always clear.
9:34 p.m.
On Thu, 2006-08-10 at 15:33 -0700, Toshio Kuratomi wrote:
On Thu, 2006-08-10 at 15:04 -0400, seth vidal wrote:
> okay - then here are a couple of more situations I want to make sure are
> understood:
>
> yum remove foo*
>
> it should remove all packages starting with foo of EVERY arch or just of
> the primary arch in the biarch set?
>
> yum update foo*
>
> ditto of above? What should it default to act on
This is interesting. In my mind I've been thinking of globs as broken
because they pull in everything. Then I start using them when I remove
something and it works as I expect! Woohoo! Next time I use it to
install something and it's still "broken"....
Now that we've had this discussion I realize this isn't broken but a
design decision. But even though I now realize it is consistent, I
still think it is unexpected.
Here's why:
yum install vim*
installs vim-common.x86_64 vim-enhanced.x86_64 vim-minimal.x86_64
yum install xfsprogs*
installs xfsprogs.x86_64 xfsprogs.i386 xfsprogs-devel.x86_64
xfsprogs-devel.i386
Why should xfsprogs install i386 packages when vim doesn't?
b/c, afaik, there is no i386 package for vim in the x86_64 tree.
-sv
9:48 p.m.
On Thu, Aug 10, 2006 at 10:34:38PM -0400, seth vidal wrote:
> Why should xfsprogs install i386 packages when vim doesn't?
b/c, afaik, there is no i386 package for vim in the x86_64 tree.
Yeah, I think that's his point -- from a user point of view, it's
unpredictable behavior.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:27 p.m.
On Thu, 2006-08-10 at 22:48 -0400, Matthew Miller wrote:
On Thu, Aug 10, 2006 at 10:34:38PM -0400, seth vidal wrote:
> > Why should xfsprogs install i386 packages when vim doesn't?
> b/c, afaik, there is no i386 package for vim in the x86_64 tree.
Yeah, I think that's his point -- from a user point of view, it's
unpredictable behavior.
is it?
yum will install all archs that it CAN
seems predictable to me.
-sv
10:47 p.m.
On Thu, Aug 10, 2006 at 11:27:40PM -0400, seth vidal wrote:
> Yeah, I think that's his point -- from a user point of view,
it's
> unpredictable behavior.
is it?
yum will install all archs that it CAN
seems predictable to me.
Yeah, but for a naive (take that however you want) user, it's unpredictable
when multiple architectures will be available for a given package.
I'm not so hung up on this particular point personally, though. I'm just
trying to explain what I think the previous poster meant.
I guess my main complaint boils down to "this behavior seems un-yumlike".
It's an intuitive dislike. I mean, disk space and bandwith are cheap enough
that there's not much of a practical problem. (Except it's annoying when
building software which wants to link against 32-bit stuff just cause hey,
it's there. But that's not yum's fault.)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11 p.m.
On Thu, Aug 10, 2006 at 11:47:23PM -0400, Matthew Miller wrote:
I guess my main complaint boils down to "this behavior seems
un-yumlike".
It's an intuitive dislike. I mean, disk space and bandwith are cheap enough
Another parallel example: sendmail, postfix, and exim all provide
smtpdaemon, but "yum install smtpdaemon" doesn't install all of those.
And "yum remove smtpdaemon" *does* try to remove all matches. Okay, this
isn't necessarily the best behavior, but it is what I expect from yum, and
it's inconsistent that arch doesn't work this way. And at least with arch,
we've got a decent way of guessing which one is "better" for installation.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11:12 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
Yeah, but for a naive (take that however you want) user, it's
unpredictable
when multiple architectures will be available for a given package.
Ah, but the 'naive' user, as you say, is probably using pup/pirut,
and never sees this stuff.
Bill
6:04 a.m.
Dnia 10-08-2006, czw o godzinie 23:47 -0400, Matthew Miller napisał(a):
I mean, disk space and bandwith are cheap enough
that there's not much of a practical problem.
Try downloading OpenOffice.org
via GPRS link. Polish GSM operators even
have a 1 GB monthly download "limit" (after which you can get few
kilobits per second or so) which makes difference between one and two
architectures of a (500 MB) package really big.
Why can't we do incremental (changed files only) updates is another
matter.
Lam
3:09 a.m.
On Thu, 2006-08-10 at 22:34 -0400, seth vidal wrote:
On Thu, 2006-08-10 at 15:33 -0700, Toshio Kuratomi wrote:
> On Thu, 2006-08-10 at 15:04 -0400, seth vidal wrote:
>
> > okay - then here are a couple of more situations I want to make sure are
> > understood:
> >
> > yum remove foo*
> >
> > it should remove all packages starting with foo of EVERY arch or just of
> > the primary arch in the biarch set?
> >
> > yum update foo*
> >
> > ditto of above? What should it default to act on
>
> This is interesting. In my mind I've been thinking of globs as broken
> because they pull in everything. Then I start using them when I remove
> something and it works as I expect! Woohoo! Next time I use it to
> install something and it's still "broken"....
>
> Now that we've had this discussion I realize this isn't broken but a
> design decision. But even though I now realize it is consistent, I
> still think it is unexpected.
>
> Here's why:
> yum install vim*
> installs vim-common.x86_64 vim-enhanced.x86_64 vim-minimal.x86_64
>
> yum install xfsprogs*
> installs xfsprogs.x86_64 xfsprogs.i386 xfsprogs-devel.x86_64
> xfsprogs-devel.i386
>
> Why should xfsprogs install i386 packages when vim doesn't?
>
b/c, afaik, there is no i386 package for vim in the x86_64 tree.
Better rhetorical question:
How should I know that yum is going to install an i386 of xfsprogs but
not vim ahead of time?
I don't know that there's an i386 version of the package within the tree
until yum tells me. So if I don't want to waste time with yum trying to
download the i386 package I need to waste time ftp'ing into the
repository to list the exact filenames of the packages I'm interested
in.
This is a case where "do what I mean" and "do what I say" don't
match
up. I think that part of it is because yum's overloading a field. In
yum install [PACKAGE], PACKAGE sometimes means package name and
PACKAGENAME.ARCH in others. If we break arch out of that field another
issue is easier to see:
On x86_64:
yum remove [multilib package]* will remove whichever versions of the
packages are present on the system.
yum remove [multilib package]* --arch=i386 will remove the i386 packages
if they exist on the system
yum upgrade [multilib package]* will upgrade whichever versions of the
packages are present on the system
yum upgrade [multilib package]* --arch=i386 will upgrade the i386
packages if they exist on the system.
yum install [multilib package]* will install the packages from the
repository.
yum install [multilib package]* --arch=i386 will install the i386
packages if they exist in the repository.
The install case is different from the remove and upgrade cases because
remove and upgrade deal with the installed system while install deals
with the repository. To be truly consistent between yum install and yum
upgrade, if I had vim-common on my system and ran "yum upgrade vim*",
yum would look in the repository, discover vim-minimal, vim-enhanced,
and vim-X11 and "upgrade" those as well. You don't have yum do that
because yum install and yum upgrade are operating in different contexts
with different expectations. If the expectation for the install case is
"best arch for the system" instead of "all packages present in the
repository" then it shouldn't be a surprise that it isn't consistent
with the upgrade or remove case for the same reason.
-Toshio
2:04 p.m.
On Thu, 2006-08-10 at 14:56 -0400, seth vidal wrote:
On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > No, I don't like the behavior of installing both arches by default.
>
> I don't personally either, but I have the capacity to fix that for my system.
> I'm just repeating the reasoning that was given to me the last time I bitched
> about it.
So everyone hates it? anyone in favor?
I'm strongly in favor. It removes some of the weirdness about caring
about which order packages get installed in as well as making things
just more consistent.
Jeremy
3 p.m.
seth vidal (skvidal(a)linux.duke.edu) said:
On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > No, I don't like the behavior of installing both arches by default.
>
> I don't personally either, but I have the capacity to fix that for my system.
> I'm just repeating the reasoning that was given to me the last time I bitched
> about it.
So everyone hates it? anyone in favor?
I like it. You install glibc, you get all the glibc relevant for your
system.
Bill
8:58 p.m.
tor, 10 08 2006 kl. 14:56 -0400, skrev seth vidal:
On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > No, I don't like the behavior of installing both arches by default.
>
> I don't personally either, but I have the capacity to fix that for my system.
> I'm just repeating the reasoning that was given to me the last time I bitched
> about it.
So everyone hates it? anyone in favor?
If you give me a simple boolean in yum.conf to turn it off I would be in
favor. I'll admit I was stunned when I first noticed the feature and I
did call for a handy little lynching but now that I've gotten used to
yum wasting my bandwidth and diskspace I just sigh and let it. I have
yet to actually experience any gain from this, so either it just works
and I didn't know there was a problem previously or it doesn't do
anything for me.
- David Nielsen
11:23 p.m.
On Fri, 2006-08-11 at 03:58 +0200, David Nielsen wrote:
tor, 10 08 2006 kl. 14:56 -0400, skrev seth vidal:
> On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> > On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > > No, I don't like the behavior of installing both arches by default.
> >
> > I don't personally either, but I have the capacity to fix that for my
system.
> > I'm just repeating the reasoning that was given to me the last time I
bitched
> > about it.
>
> So everyone hates it? anyone in favor?
If you give me a simple boolean in yum.conf to turn it off I would be in
favor. I'll admit I was stunned when I first noticed the feature and I
did call for a handy little lynching but now that I've gotten used to
yum wasting my bandwidth and diskspace I just sigh and let it. I have
yet to actually experience any gain from this, so either it just works
and I didn't know there was a problem previously or it doesn't do
anything for me.
a simple boolean?
does:
exclude=*i?86
work for you?
-sv
12:03 a.m.
On Fri, 2006-08-11 at 00:23 -0400, seth vidal wrote:
On Fri, 2006-08-11 at 03:58 +0200, David Nielsen wrote:
> tor, 10 08 2006 kl. 14:56 -0400, skrev seth vidal:
> > On Thu, 2006-08-10 at 14:51 -0400, Jesse Keating wrote:
> > > On Thursday 10 August 2006 14:48, Panu Matilainen wrote:
> > > > No, I don't like the behavior of installing both arches by
default.
> > >
> > > I don't personally either, but I have the capacity to fix that for my
system.
> > > I'm just repeating the reasoning that was given to me the last time I
bitched
> > > about it.
> >
> > So everyone hates it? anyone in favor?
>
> If you give me a simple boolean in yum.conf to turn it off I would be in
> favor. I'll admit I was stunned when I first noticed the feature and I
> did call for a handy little lynching but now that I've gotten used to
> yum wasting my bandwidth and diskspace I just sigh and let it. I have
> yet to actually experience any gain from this, so either it just works
> and I didn't know there was a problem previously or it doesn't do
> anything for me.
>
a simple boolean?
does:
exclude=*i?86
work for you?
No, that doesn't work for us.
The behavior we (well, I, anyway) want is as follows:
== Definitions ==
UnqualifiedPackageName:
A package name or wildcard matching one of the following forms:
%{name}
%{name}-%{version}
%{name}-%{version}-%{release}
%{name}-%{epoch}:%{version}-%{release}
QualifiedPackageName:
A package name or wildcard matching the following form:
UnqualifiedPackageName.%{arch}
== Behavior ==
Note that in the following descriptions, I use "match" to mean "consider
as possible candidates for a match." Also note that this description
only applies to yum's behavior parsing package arguments on the command
line or yum shell prompt (and possibly other programmatic interfaces, as
appropriate).
yum behavior in the presence of an UnqualifiedPackageName:
install: match only {x86_64,noarch} packages, unless no such package
exists, then match i?86 packages
update: match any package currently installed, regardless of arch
upgrade: match any package currently installed, regardless of arch
remove: match any package currently installed, regardless of arch
list: match any package, regardless of arch
info: match any package currently installed, regardless of arch,
otherwise match any package
deplist: match any package, regardless of arch
yum behavior in the presence of a QualifiedPackageName:
install: match any package
update: match any package currently installed
upgrade: match any package currently installed
remove: match any package currently installed
list: match any package
info: match any package currently installed,
otherwise match any package
deplist: match any package
In short, when I say "yum install flac", I expect only flac.x86_64 to be
installed. When I say "yum install openoffice.org-writer", I expect it
to work, which "exclude=*.i?86" won't give me.
Is that clear enough?
--
Nicholas Miell <nmiell(a)comcast.net>
10:38 a.m.
seth vidal wrote:
On Thu, 2006-08-10 at 11:02 -0400, Matthew Miller wrote:
> On Thu, Aug 10, 2006 at 04:48:41PM +0200, Ralf Ertzinger wrote:
>>> Are you concerned that there might be a package
>>> "foobarin86-5.3-1.fc6.x86_64"?
>>> I guess "." is kind of an unfortunate separator for arch.....
>> That depends whether that's a shell glob or a regexp :)
> The pattern is already defined as being a shell glob.
>
> Seth, gimmie a hint. What's the issue you're worried about here? :)
>
I'm worried about someone legitimately wanting to install both arches
being stymied by this "feature".
Erm, speaking as a multilib feature, I think an overwelming percentage
of multilib user wants the suggested feature. Also most yum cmdline
using multilib user (aka powerusers, who might want both versions) are
currently used to adding .x86_64 to every package mentioned in a yum
something command, so if they really want both I'm sure they can figure
out to add the packagename twice to the cmdline list, once with .x86_64
appended, and once with .i386 .
I already have been running with both i386 and x86_64 repos of core and
extras in my /etc/yum.repos.d and have not complained because this is an
unsupported setup, however the way as things currently work is annoying
and the suggested feature would make life much easier.
I review quite a few packages and often rpmbuild refuses to build the
SRPM I'm reviewing because of a missing dep on foo-devel, if I then
accidently (which still sometimes happens) type:
sudo yum -y install foo-devel
instead of
sudo yum -y install foo-devel.x86_64
I get both versions, which is not what I wanted! I believe the current
behaviour even though documented is annoying enough to almost warrent
the title bug and I would love to see the suggested feature.
Notice that this feature should preferably not only be added to the
cmdline parsing but also to dep resolving.
Sometimes a package will Require /usr/bin/foo, now if /usr/bin/foo is
not in my system when I'm installing this package and /usr/bin/foo is
provided by bar then yum will install both the i386 and x86_64 versions
of bar, which is BAD. This is optimised for the exception that some
package requires a file and somehow requires that file to be of a
certain arch, which is crazy, because either the file is an executable,
in which case either version should work fine (or the Requires is broken
and the requiering package should be fixed), or it is not an executable
in which case the versions in the i386 and x86_64 package must be
indentical otherwise I'll get a file conflict.
Regards,
Hans
6501
days inactive
6505
days old
47 comments
18 participants
participants (18)
-
Bill Nottingham -
Chris Adams -
David Nielsen -
Hans de Goede -
Jeremy Katz -
Jesse Keating -
John DeDourek -
Leszek Matok -
Matthew Miller -
Matthias Saou -
Naoki -
Nicholas Miell -
Nicolas Mailhot -
Panu Matilainen -
Rahul Sundaram -
Ralf Ertzinger -
seth vidal -
Toshio Kuratomi