Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
I ask because of the following:
# yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root@apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386
Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking.
Can this be done in packaging, or does this need to be done in rpm?
On Wed, 11 Apr 2007, Bill Nottingham wrote:
Orion Poplawski (orion@cora.nwra.com) said:
Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
Doesn't work, so... no.
Doesn't work, but interesting timing :) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
- Panu -
On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote:
On Wed, 11 Apr 2007, Bill Nottingham wrote:
Orion Poplawski (orion@cora.nwra.com) said:
Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
Doesn't work, so... no.
Doesn't work, but interesting timing :) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
I'd like to offer a HELL NO in reference to that syntax.
-sv
Le Jeu 12 avril 2007 09:06, seth vidal a écrit :
On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote:
On Wed, 11 Apr 2007, Bill Nottingham wrote:
Orion Poplawski (orion@cora.nwra.com) said:
Here's a question. Should -devel package requirements be of the
form:
Requires: package-devel.%{arch}
Doesn't work, so... no.
Doesn't work, but interesting timing :) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
I'd like to offer a HELL NO in reference to that syntax.
Please someone explain JBJ that spec syntax must be parseable by humans, and Arch(foo) will only make packagers try Version(foo).
Sanity demands foo(arch=x and version >y) if he wants packagers to tokenize EVR for him
On Thu, 2007-04-12 at 09:32 +0200, Nicolas Mailhot wrote:
Le Jeu 12 avril 2007 09:06, seth vidal a écrit :
On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote:
On Wed, 11 Apr 2007, Bill Nottingham wrote:
Orion Poplawski (orion@cora.nwra.com) said:
Here's a question. Should -devel package requirements be of the
form:
Requires: package-devel.%{arch}
Doesn't work, so... no.
Doesn't work, but interesting timing :) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
I'd like to offer a HELL NO in reference to that syntax.
Please someone explain JBJ that spec syntax must be parseable by humans, and Arch(foo) will only make packagers try Version(foo).
Sanity demands foo(arch=x and version >y) if he wants packagers to tokenize EVR for him
how about arch >= i386
so that would include x86_64, too, right? :)
/me runs
-sv
Le Jeu 12 avril 2007 09:51, seth vidal a écrit :
On Thu, 2007-04-12 at 09:32 +0200, Nicolas Mailhot wrote:
Le Jeu 12 avril 2007 09:06, seth vidal a écrit :
I'd like to offer a HELL NO in reference to that syntax.
Please someone explain JBJ that spec syntax must be parseable by humans, and Arch(foo) will only make packagers try Version(foo).
Sanity demands foo(arch=x and version >y) if he wants packagers to tokenize EVR for him
how about arch >= i386
so that would include x86_64, too, right? :)
foo(arch=i386 or arch=x86_64) ?
/me runs
You can't escape rpm indefinitely :)
On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote:
Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
Maybe it makes more sense to disallow rpm from satisfying cross-arch dependencies at all. noarch belongs to all archs in this sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 packages to satisfy depednencies of x86_64 and vice-versa.
I ask because of the following:
# yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root@apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386
Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking.
Can this be done in packaging, or does this need to be done in rpm?
On Thursday 12 April 2007 05:31:37 Axel Thimm wrote:
noarch belongs to all archs in this sense
Except where they don't, when we really don't want a noarch package on a particular arch, and right now we don't have a good way of doing this :/
On Thu, Apr 12, 2007 at 07:20:29AM -0400, Jesse Keating wrote:
On Thursday 12 April 2007 05:31:37 Axel Thimm wrote:
noarch belongs to all archs in this sense
Except where they don't, when we really don't want a noarch package on a particular arch, and right now we don't have a good way of doing this :/
But that's a complete different topic, no? We're not talking about what to have in the repo, but when it is there, what to allow for fulfilling dependencies, e.g. build/runtime resolving of dependencies (rpm) vs repo construction policies (<your favourite buildsystem>).
On Thu, 12 Apr 2007, Axel Thimm wrote:
On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote:
Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
Maybe it makes more sense to disallow rpm from satisfying cross-arch dependencies at all. noarch belongs to all archs in this sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 packages to satisfy depednencies of x86_64 and vice-versa.
That doesn't quite fly either, it's perfectly valid for a package to require eg "webclient" for viewing html content and the app doesn't care if the client is 32bit or 64bit, just as long as it does the job.
I ask because of the following:
# yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root@apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386
Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking.
Can this be done in packaging, or does this need to be done in rpm?
I don't see why it couldn't be done in packaging with something like "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel package.. or some similar manual construct.
Whether requiring yet more manual cruft to be added to almost each and every package is desirable or feasible is a whole another question :)
- Panu -
On Thu, Apr 12, 2007 at 03:29:09PM +0300, Panu Matilainen wrote:
On Thu, 12 Apr 2007, Axel Thimm wrote:
On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote:
Here's a question. Should -devel package requirements be of the form:
Requires: package-devel.%{arch}
Maybe it makes more sense to disallow rpm from satisfying cross-arch dependencies at all. noarch belongs to all archs in this sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 packages to satisfy depednencies of x86_64 and vice-versa.
That doesn't quite fly either, it's perfectly valid for a package to require eg "webclient" for viewing html content and the app doesn't care if the client is 32bit or 64bit, just as long as it does the job.
I don't see why it couldn't be done in packaging with something like "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel package.. or some similar manual construct.
Because ... see your own answer below :)
Whether requiring yet more manual cruft to be added to almost each and every package is desirable or feasible is a whole another question :)
Indeed, if we want to solve this it would have to be some solution that can leave the specfiles at peace. That's why I suggest to change rpm's interpretation instead of adding new syntax. Maybe the above isn't the best solution, yet, but perhaps it hints to a better one. E.g. I'd prefer to come to a solution where only "webclient" needs special treatment and new syntax, since that would mean touching a dozen packages and not some thousands :)
But I feel that this is outside the packaging group's domain, we don't develop rpm. Maybe Orion should file a bug against rpm?
On Thursday 12 April 2007, Axel Thimm wrote:
On Thu, Apr 12, 2007 at 03:29:09PM +0300, Panu Matilainen wrote:
I don't see why it couldn't be done in packaging with something like "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel package.. or some similar manual construct.
Because ... see your own answer below :)
Whether requiring yet more manual cruft to be added to almost each and every package is desirable or feasible is a whole another question :)
Indeed, if we want to solve this it would have to be some solution that can leave the specfiles at peace.
Making rpmbuild autogenerate the Provides would probably be pretty easy. For the requires, it'd be pretty much a matter of adding the .$arch to the dependencies that are already explicitly listed in specfiles.
By the way, %{_arch} is not the thing to use for this, %{_target_cpu} would be closer but not quite there either; dunno if a suitable variable actually exists. Think eg. building a package for i686 that has a dependency on something of the same arch which needs to be added explicitly in the specfile - i386, i486, i586 and/or i686 of that dependency would likely work.
Panu Matilainen wrote :
I don't see why it couldn't be done in packaging with something like "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel package.. or some similar manual construct.
Whether requiring yet more manual cruft to be added to almost each and every package is desirable or feasible is a whole another question :)
<sarcasm> Hmmmm... I can't seem to remember why it is that we bloat some archs with that "multilib" hack in the first place... oh, yeah, the flash browser plugin!
The only downsides being wasted disk space, wasted yum processing time, wasted bandwidth and missing documentations and translations for people trying to clean things up. </sarcasm>
Well... err... sorry for the flamebait... /me runs
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
(this said, on a quite simple FC6 x86_64 install on which I've done "yum remove glibc.i686" post-install, gnome-terminal crashes in some /usr/lib64/gconv/ library, which I suspect has something to do with multilib and rpm removing translations... but even after nearly two hours, I still couldn't figure out where the problem lies... glibc, some libgnome*... dunno...)
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
-sv
seth vidal wrote :
On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
s/plugins/proprietary plugins only available for 32bit x86/
...and the answer could be : Shouldn't we care about as much as how to install proprietary video drivers or patent encumbered codecs? :-)
Matthias
On Thu, 2007-04-12 at 15:24 +0200, Matthias Saou wrote:
seth vidal wrote :
On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
s/plugins/proprietary plugins only available for 32bit x86/
...and the answer could be : Shouldn't we care about as much as how to install proprietary video drivers or patent encumbered codecs? :-)
okie doke. I can understand that. If you don't want multilib pkgs installed then that's do-able. But I'm not the person to convince of it and I don't think it comes back to me to decide this for the distribution.
-sv
On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
yum install firefox.i386 ?
With the default being to match "bestarch" if none is given.
Okay, what am I missing? :)
On Thu, 2007-04-12 at 10:52 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
yum install firefox.i386 ?
With the default being to match "bestarch" if none is given.
Okay, what am I missing? :)
FWIW, I'm still not sure why we don't do this:
x86_64 repo (with all x86_64 packages and firefox.i386 and deps as ONLY i386 packages) i386 repo (with all i386 packages)
x86_64 installs include yum config for i386 repo, but it is disabled by default. You want multilib, enable the i386 repo.
I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox.
~spot
On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote:
I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox.
+1,000,000. :)
Le Jeu 12 avril 2007 17:07, Matthew Miller a écrit :
On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote:
I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox.
+1,000,000. :)
I'm full 64bit on my box precisely because flash was not worth the pain of dealing with multilib
Nicolas Mailhot wrote :
Le Jeu 12 avril 2007 17:07, Matthew Miller a écrit :
On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote:
I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox.
+1,000,000. :)
I'm full 64bit on my box precisely because flash was not worth the pain of dealing with multilib
The only computer where I have left multilib packages installed is my main workstation, to get 32bit firefox, but in my case too it's the only thing I wanted... that's the first issue.
The second issue is yum's default behaviour of installing all available archs for the requested package, which annoys me quite a lot. Today alone I had to re-run yum quite a few times after wanting to install some devel packages I needed to phpize some PHP modules... no, I don't want the 32bit devel package! ;-)
Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment?
Matthias
On Thu, 2007-04-12 at 20:33 +0200, Matthias Saou wrote:
Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment?
No, the 64bit version is.
MOZ_ARCH=$(uname -m) case $MOZ_ARCH in x86_64 | ia64 | s390 ) MOZ_LIB_DIR="/usr/lib64" SECONDARY_LIB_DIR="/usr/lib" ;; * ) MOZ_LIB_DIR="/usr/lib" SECONDARY_LIB_DIR="/usr/lib64" ;; esac
if [ ! -x $MOZ_LIB_DIR/firefox-2.0.0.3/firefox-bin ]; then if [ ! -x $SECONDARY_LIB_DIR/firefox-2.0.0.3/firefox-bin ]; then echo "Error: $MOZ_LIB_DIR/firefox-2.0.0.3/firefox-bin not found" if [ -d $SECONDARY_LIB_DIR ]; then echo " $SECONDARY_LIB_DIR/firefox-2.0.0.3/firefox-bin not found" fi exit 1 fi MOZ_LIB_DIR="$SECONDARY_LIB_DIR" fi
~spot
On Thu, Apr 12, 2007 at 08:33:10PM +0200, Matthias Saou wrote:
Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment?
64 by default. Install "firefox-32" from extras to get an icon that runs the 32-bit version.
Matthew Miller wrote :
On Thu, Apr 12, 2007 at 08:33:10PM +0200, Matthias Saou wrote:
Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment?
64 by default. Install "firefox-32" from extras to get an icon that runs the 32-bit version.
Ok, then the current situation doesn't make much sense to me since it still requires some "manual work", i.e. either : - Install that firefox-32 package (and/or) - Remove the x86_64 firefox package
I did the latter, but IIRC it is preventing me from installing some apps that are only available in 64bit and require the gecko engine which still hasn't been split out.
Anyway, in the end my vote would be to change yum's behaviour from "install all available archs of the latest version" to "install best available arch of the latest version" when no arch is specified, and not have anaconda install any compat 32bit packages by default.
As a side note, this is something I have always found quite annoying too : Any explicit package requirement from within a package also "triggers" the installation of all available archs (which is actually coherent with the current behavior, but annoying nevertheless). Example : If your package explicitly "Requires: curl" although it only really requires libcurl.so.3, which rpm also added automatically, you'll end up with curl.i386 and dragging in all of its dependencies. Without the explicit requirement, only curl.x86_64 would have been necessary.
Matthias
On Thu, Apr 12, 2007 at 09:09:47PM +0200, Matthias Saou wrote:
Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment?
64 by default. Install "firefox-32" from extras to get an icon that runs the 32-bit version.
Ok, then the current situation doesn't make much sense to me since it still requires some "manual work", i.e. either :
- Install that firefox-32 package
(and/or)
- Remove the x86_64 firefox package
Good point.
Anyway, in the end my vote would be to change yum's behaviour from "install all available archs of the latest version" to "install best available arch of the latest version" when no arch is specified, and not have anaconda install any compat 32bit packages by default.
Plus we can add in the firefox-32 package if need be, if there's not something I'm missing about the dep change that makes it also pull in the 32-bit package.
On Thursday 12 April 2007 15:09:47 Matthias Saou wrote:
I did the latter, but IIRC it is preventing me from installing some apps that are only available in 64bit and require the gecko engine which still hasn't been split out.
And it won't either. Mozilla decided that they don't want gecko to be a platform.
Anyway, in the end my vote would be to change yum's behaviour from "install all available archs of the latest version" to "install best available arch of the latest version" when no arch is specified, and not have anaconda install any compat 32bit packages by default.
As a side note, this is something I have always found quite annoying too : Any explicit package requirement from within a package also "triggers" the installation of all available archs (which is actually coherent with the current behavior, but annoying nevertheless). Example : If your package explicitly "Requires: curl" although it only really requires libcurl.so.3, which rpm also added automatically, you'll end up with curl.i386 and dragging in all of its dependencies. Without the explicit requirement, only curl.x86_64 would have been necessary.
Those are packaging bugs regardless of how yum / rpm handle them. Explicit Requires should be avoided if the rpm will pick up library requirements on its own.
Matthias Saou schrieb:
Nicolas Mailhot wrote :
Le Jeu 12 avril 2007 17:07, Matthew Miller a écrit :
On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote:
I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox.
+1,000,000. :)
I'm full 64bit on my box precisely because flash was not worth the pain of dealing with multilib
The only computer where I have left multilib packages installed is my main workstation, to get 32bit firefox, but in my case too it's the only thing I wanted... that's the first issue.
Well, I have firefox.i386 on my x86_64 machines, too. The only other x86-apps I use now and then is acroread (which has some i386 deps), where evince doesn't work (forms).
The second issue is yum's default behaviour of installing all available archs for the requested package, which annoys me quite a lot. Today alone I had to re-run yum quite a few times after wanting to install some devel packages I needed to phpize some PHP modules... no, I don't want the 32bit devel package! ;-)
+1 -- Agreed. Is really bad for *-devel.i386 packages IMHO, as they track in lots of i386-userland packages that are hard to get rid of cleanly, because - the bug of rpm that removes some of the some files that are parts of both the i386 and the x86_64 package (docs for example iirc) - "package-cleanup --leaves all" doesn't find all of them (#235496) - something as I just forgot again
I actually had a rant about it in my blog some days ago http://thorstenl.blogspot.com/2007/04/exclude-develi386.html (which received a reply from dwmw2 at http://www.advogato.org/person/dwmw2/diary.html?start=160 )
Maybe we should move this discussion to fedora-devel? This is something for FESCo afaics, and not for the PC.
[...]
Cu thl
On Thu, 2007-04-12 at 10:52 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote:
Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p
Someday we'll convince Seth to come around on this. :)
And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins?
yum install firefox.i386 ?
With the default being to match "bestarch" if none is given.
Okay, what am I missing? :)
"Why am I installing this older arch on my system?" "What's an 'arch'?" "Why can't fedora just work?" "Why do I have to mess with all this stuff just to see web pages?"
-sv
On Thu, Apr 12, 2007 at 10:59:11AM -0400, seth vidal wrote:
yum install firefox.i386 ? With the default being to match "bestarch" if none is given. Okay, what am I missing? :)
"Why am I installing this older arch on my system?" "What's an 'arch'?" "Why can't fedora just work?" "Why do I have to mess with all this stuff just to see web pages?"
Anaconda could run with bestarch=0 to cover this.
Hmmm, actually, is firefox really the only case we care about?
Warren's "firefox-32" kludge says in the spec file "Unfortunately, we cannot have a Requires line that explicitly means /usr/lib/ 32bit firefox." But using "Requires: /usr/lib/firefox-2.0.0.3/firefox-bin" works for me. That's a bit annoying because of the version number -- either the 32-bit package would have to provide a unique, non-versioned file [*], or the firefox-32 package would have to be updated simultaneously with each firefox release.
But having that requires line in there makes it so if I yum install the x86_64 firefox-32, it pulls in firefox.i386....
This all seems so easy I *must* be missing something. :)
* other than "/etc/gre.d/gre.conf", which is too kludgy even for me.
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
(this said, on a quite simple FC6 x86_64 install on which I've done "yum remove glibc.i686" post-install, gnome-terminal crashes in some /usr/lib64/gconv/ library, which I suspect has something to do with multilib and rpm removing translations... but even after nearly two hours, I still couldn't figure out where the problem lies... glibc, some libgnome*... dunno...)
Try rpm -Va 2>&1 | grep missing
Axel Thimm wrote :
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
(this said, on a quite simple FC6 x86_64 install on which I've done "yum remove glibc.i686" post-install, gnome-terminal crashes in some /usr/lib64/gconv/ library, which I suspect has something to do with multilib and rpm removing translations... but even after nearly two hours, I still couldn't figure out where the problem lies... glibc, some libgnome*... dunno...)
Try rpm -Va 2>&1 | grep missing
Done that, waaaaaaaayyyyy too many docs and translations gone. I forced a reinstall of the packages I thought could be the cause (i.e. glibc*, libgnome, gtk2/glib2 etc.) but without any apparent success.
Anyway, my point was that from my POV multilib is ugly (I think we're all aware of that and all agree...), and that I still don't like the fact that it's forced upon all users by default (this is where opinions are much more mixed).
Arch dependencies isn't something we would have to worry about if we weren't doing all of this ugly mixing of archs on single systems ;-)
Matthias
On Thu, Apr 12, 2007 at 03:22:00PM +0200, Matthias Saou wrote:
Axel Thimm wrote :
On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote:
(this said, on a quite simple FC6 x86_64 install on which I've done "yum remove glibc.i686" post-install, gnome-terminal crashes in some /usr/lib64/gconv/ library, which I suspect has something to do with multilib and rpm removing translations... but even after nearly two hours, I still couldn't figure out where the problem lies... glibc, some libgnome*... dunno...)
Try rpm -Va 2>&1 | grep missing
Done that, waaaaaaaayyyyy too many docs and translations gone. I forced a reinstall of the packages I thought could be the cause (i.e. glibc*, libgnome, gtk2/glib2 etc.) but without any apparent success.
Anyway, my point was that from my POV multilib is ugly (I think we're all aware of that and all agree...),
In fact, I like multilib/multiarch. It isn't the general concept that sucks, but our overwrite concept and the buggy implementation in rpm.
and that I still don't like the fact that it's forced upon all users by default (this is where opinions are much more mixed).
Arch dependencies isn't something we would have to worry about if we weren't doing all of this ugly mixing of archs on single systems ;-)
Matthias
Axel Thimm wrote:
On Thu, Apr 12, 2007 at 03:22:00PM +0200, Matthias Saou wrote:
Try rpm -Va 2>&1 | grep missing
Done that, waaaaaaaayyyyy too many docs and translations gone. I forced a reinstall of the packages I thought could be the cause (i.e. glibc*, libgnome, gtk2/glib2 etc.) but without any apparent success.
Anyway, my point was that from my POV multilib is ugly (I think we're all aware of that and all agree...),
In fact, I like multilib/multiarch. It isn't the general concept that sucks, but our overwrite concept and the buggy implementation in rpm.
And buggy packages marking items as %doc that aren't truly optional.
-- Rex
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Jesse Keating -
Matthew Miller -
Matthias Saou -
Nicolas Mailhot -
Orion Poplawski -
Panu Matilainen -
Rex Dieter -
seth vidal -
Thorsten Leemhuis -
Tom Callaway -
Ville Skyttä