[arch-general] pacman's "Depends On"
Hi :) if a dedicated version of a dependency is needed, some packages mention it, others don't. Firefox does not explicitly mention a version of libvpx $ pacman -Si firefox | grep On Depends On : [snip] libvpx [snip] but it needs a dedicated version $ firefox XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so: libvpx.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. ffmpeg does mentions that a dedicated version is needed $ pacman -Si ffmpeg | grep On Depends On : [snip] libvpx.so=2-64 [snip] IMO official packages should mention dedicated versions, since for users of a rolling release, there sometimes are good reasons to downgrade. I tried to build Firefox from ABS against the outdated version of libvpx that is needed and installed on my system, but that's another issue. Perhaps other packages are broken too and I get aware of it, at an inconvenient time. How can I figure out what packages depend on a dedicated version of another package? Regards, Ralf
It's working fine for me...
% pacman -Qs libvp
local/libvpx 1.4.0-2
VP8 and VP9 codec
% pacman -Qs firefox
local/firefox 37.0.2-1
Standalone web browser from mozilla.org
% pacman -Qs ffmpeg
local/ffmpeg 1:2.6.2-1
Complete and free Internet live audio and video broadcasting solution
are you sure everything is updated and you aren't using testing?!
On Thu, Apr 23, 2015 at 4:18 PM, Ralf Mardorf
Hi :)
if a dedicated version of a dependency is needed, some packages mention it, others don't.
Firefox does not explicitly mention a version of libvpx
$ pacman -Si firefox | grep On Depends On : [snip] libvpx [snip]
but it needs a dedicated version
$ firefox XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so: libvpx.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM.
ffmpeg does mentions that a dedicated version is needed
$ pacman -Si ffmpeg | grep On Depends On : [snip] libvpx.so=2-64 [snip]
IMO official packages should mention dedicated versions, since for users of a rolling release, there sometimes are good reasons to downgrade.
I tried to build Firefox from ABS against the outdated version of libvpx that is needed and installed on my system, but that's another issue.
Perhaps other packages are broken too and I get aware of it, at an inconvenient time.
How can I figure out what packages depend on a dedicated version of another package?
Regards, Ralf
On Thu, 23 Apr 2015 17:06:39 +0200, Simon Hanna wrote:
are you sure everything is updated and you aren't using testing?!
Hi, I'm aware that libvpx isn't up to date on my machine. I need to keep an outdated version of Virtualmachine and to run it, I need the outdated version of libvpx. $ pacman -Q libvpx ; pacman -Si libvpx | grep Ver libvpx 1.3.0-1 Version : 1.4.0-2 Some packages mention that they need a dedicated version of libvpx. $ pacman -Si ffmpeg ffmpeg-compat | grep On Depends On : [snip] libvpx.so=2-64 [snip] Depends On : [snip] libvpx.so=2-64 [snip] ^^^^^ Pointer to the needed version So I'm aware about it and forced to downgrade those ffmpeg packages too, that's what I did. Alternatively I also could use ABS and try to build them against the outdated libvpx, what I try to do at the moment with Firefox. However, Firfox allowed me to install the wrong version and didn't start. $ pacman -Qi firefox | grep On Depends On : [snip] libvpx [snip] ^^^^^^ No pointer to a dedicated version So I'm aware that the Virtualmachine packages, the libvpx and 2 ffmpeg packages for good reasons aren't up to date. I didn't notice that Firefox needs the up to date version of libvpx too. I wonder if there's a way to list all packages that depend on a dedicated version of another package. Regards, Ralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I didn't notice that Firefox needs the up to date version of libvpx too. I wonder if there's a way to list all packages that depend on a dedicated version of another package.
arch does not support partial upgrades. it is simply to much of a hassle, to keep track of every versioned dependency. so, if you choose to update partially, you have to deal with it on your own (as you already do). i think there have been several diskussions about that on this ML, so if you need more info, maybe a search in the archives can help you. greetz g -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVORLtAAoJELKHx5nAxn3sTGYIANG842h8Vixg8XEMkljME58f Bab3xN+2OgVRn02D4v20q9LzPGEhwSIcqzRZ7Q1MG4SF7IdUo3Ew51tpj2xGJ5l9 CFRMAER6/j+Y4+AnAQoDD0btJQaZn3UzEhKCuxi+V/EnkLuxFSOnlGDXCImNgbWI Ogjc1R706tEWReRA4hYtZjikx4RbsfyFBrWncdrjJJQIQk+KGbRPlHPwfEDFxffA RRitoa01CXlzes+lNYCQP/ldwz2pZ54kGfN+yUoBEw1Ww3BOXIP/kKtBABEUIMgW FIoC++kxCXngZPsGOXXS53c9OmFhUPXlyeZVwt5L4krR7rIFg/YBX97Tdh4lOjE= =qAsk -----END PGP SIGNATURE-----
On Thu, 23 Apr 2015 17:42:44 +0200, G. Schlisio wrote:
arch does not support partial upgrades. it is simply to much of a hassle, to keep track of every versioned dependency. so, if you choose to update partially, you have to deal with it on your own (as you already do). i think there have been several diskussions about that on this ML, so if you need more info, maybe a search in the archives can help you.
Thank you. I guess I will search for another solution. Maybe a chroot for the outdated version of virtualbox. OTOH I don't know if a chroot won't cause USB issues. At the moment I can keep it the way it is, but within a few month it might be better to find another solution. Regards, Ralf
On 23-04-2015 16:57, Ralf Mardorf wrote:
On Thu, 23 Apr 2015 17:42:44 +0200, G. Schlisio wrote:
arch does not support partial upgrades. it is simply to much of a hassle, to keep track of every versioned dependency. so, if you choose to update partially, you have to deal with it on your own (as you already do). i think there have been several diskussions about that on this ML, so if you need more info, maybe a search in the archives can help you.
Thank you.
I guess I will search for another solution. Maybe a chroot for the outdated version of virtualbox. OTOH I don't know if a chroot won't cause USB issues.
At the moment I can keep it the way it is, but within a few month it might be better to find another solution.
Regards, Ralf
You should give qemu+kvm+spice a try, I have found that it seems to work acceptably even for usb redirection. Bonus points: no more trouble after updates and it should work over the network. -- Mauro Santos
On Thu, 23 Apr 2015 18:18:49 +0100, Mauro Santos wrote:
You should give qemu+kvm+spice a try, I have found that it seems to work acceptably even for usb redirection. Bonus points: no more trouble after updates and it should work over the network.
Thank you, I agree. The reason that I didn't drop Virtualbox and tested other hosts is, that I don't know how to get my Windows XP SP3 guest from $ ls -hlG Virt*/winOS/*.vdi -rw------- 1 rocketmouse 28G Apr 20 23:31 VirtualBox VMs/winOS/winOS.vdi to another host. It seems to be hard or perhaps impossible to restore a Win XP from a backup. I at least can't remember that it ever worked for me. If possible I want to restore Win XP from a backup, when migrating to another VM. Any hints how to backup Win XP and restore it on another virtual machine are welcome. Regards, Ralf
On 23/04/15 at 04:18pm, Ralf Mardorf wrote:
Hi :)
if a dedicated version of a dependency is needed, some packages mention it, others don't.
Firefox does not explicitly mention a version of libvpx
$ pacman -Si firefox | grep On Depends On : [snip] libvpx [snip]
but it needs a dedicated version
$ firefox XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so: libvpx.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM.
ffmpeg does mentions that a dedicated version is needed
$ pacman -Si ffmpeg | grep On Depends On : [snip] libvpx.so=2-64 [snip]
IMO official packages should mention dedicated versions, since for users of a rolling release, there sometimes are good reasons to downgrade.
I tried to build Firefox from ABS against the outdated version of libvpx that is needed and installed on my system, but that's another issue.
Perhaps other packages are broken too and I get aware of it, at an inconvenient time.
How can I figure out what packages depend on a dedicated version of another package?
Regards, Ralf
Hello Ralf, Maybe you should specify which packages to be ignored via 'IgnorePkg' variable, here is the link https://wiki.archlinux.org/index.php/Downgrading_packages#How_do_I_stop_pacm... Best regards, Aaron Caffrey
2015-04-23 20:31 GMT+02:00 Ralf Mardorf
On Thu, 23 Apr 2015 18:18:49 +0100, Mauro Santos wrote:
You should give qemu+kvm+spice a try, I have found that it seems to work acceptably even for usb redirection. Bonus points: no more trouble after updates and it should work over the network.
Thank you,
I agree. The reason that I didn't drop Virtualbox and tested other hosts is, that I don't know how to get my Windows XP SP3 guest from
$ ls -hlG Virt*/winOS/*.vdi -rw------- 1 rocketmouse 28G Apr 20 23:31 VirtualBox VMs/winOS/winOS.vdi
to another host. It seems to be hard or perhaps impossible to restore a Win XP from a backup. I at least can't remember that it ever worked for me.
If possible I want to restore Win XP from a backup, when migrating to another VM. Any hints how to backup Win XP and restore it on another virtual machine are welcome.
Sticking with qemu for the moment (but the same program can be used for many formats); you can use qemu-img convert to copy your XP vdi to e.g. qcow2 or RAW and use that for $other vm. The openstack project has nice documentation on this: http://docs.openstack.org/image-guide/content/ch_converting.html Note though, that plain qemu can be a bit cumbersome, nice frontends are available (I've used libvirt with some success in the past). mvg, Guus
On Thu, 23 Apr 2015 21:01:21 +0200, Aaron Caffrey wrote:
Maybe you should specify which packages to be ignored via 'IgnorePkg'
Hi Aaron, the problem is that a user first needs to test which software depends on a dedicated version of a dependency and wich version doesn't. $ pacman -Qi libvpx | grep By Required By : ffmpeg ffmpeg-compat firefox [snip] tor-browser-en [snip] ffmpeg and ffmpeg-compat mention that they need a dedicated version of libvpx, while firefox doesn't. tor-browser-en still works with the old version, haven't tested it with the new version, since it's a package from AUR, it might need the old version and needs to be rebuild, when using the new version. IOW my request is related to the way dependencies are listed. I'm already using IgnorePkg, I will use it for Firefox too, but 1. I wasn't aware that Firefox depends to a dedicated version of libvpx and 2. I will build some software from ABS, especially Internet related software. Btw. "it is simply to much of a hassle, to keep track of every versioned dependency" - G. Schlisio That's reasonable. Resume: You only can add a package to the IgnorePkg list, if you are aware that you need to prevent it from getting updated. The funny thing is, that I noticed a broken Virtualbox after upgrading systemd. Instead of checking what packages are needed by virtualbox, I suspected systemd to be the culprit. A pacman -Qi virtualbox would have shown me, that the culprit was an update I did a few hours before. IOW I was very stupid. However, assumed virtualbox would have mentioned that it depends on a dedicated version of libvpx, pacman would have forbidden the update. Schlisio's argument that it's much work is reasonable. Regards, Ralf
What you need to do is to create a custom package for the specific version of libvpx that doesn't conflict with the one from repo, so you can have both the new version for repo packages and the old version for whatever reason
On 23-04-2015 19:31, Ralf Mardorf wrote:
On Thu, 23 Apr 2015 18:18:49 +0100, Mauro Santos wrote:
You should give qemu+kvm+spice a try, I have found that it seems to work acceptably even for usb redirection. Bonus points: no more trouble after updates and it should work over the network.
Thank you,
I agree. The reason that I didn't drop Virtualbox and tested other hosts is, that I don't know how to get my Windows XP SP3 guest from
$ ls -hlG Virt*/winOS/*.vdi -rw------- 1 rocketmouse 28G Apr 20 23:31 VirtualBox VMs/winOS/winOS.vdi
to another host. It seems to be hard or perhaps impossible to restore a Win XP from a backup. I at least can't remember that it ever worked for me.
If possible I want to restore Win XP from a backup, when migrating to another VM. Any hints how to backup Win XP and restore it on another virtual machine are welcome.
Regards, Ralf
You can make a copy of that image and try to run it directly with qemu, it might just work, although it might not be optimal in terms of speed. What can be quite tricky is the change in emulated hardware, Windows does not like that and will most probably throw a fit. Changing the image format is not hard, run qemu with 2 virtual disks, one the vdi another a raw image and use a live cd to dd/cp from one disk to the other, or use any tool that does the conversion. However I would say do a clean install if you can and use virtio devices from the start. -- Mauro Santos
On Thu, 23 Apr 2015 22:56:56 +0300, Jesse Jaara wrote:
What you need to do is to create a custom package for the specific version of libvpx that doesn't conflict with the one from repo, so you can have both the new version for repo packages and the old version for whatever reason
Yes, I was thinking of simply installing the new package and copying /usr/lib/libvpx.so.1.3.0 from a backup and add the links /usr/lib/libvpx.so.1 /usr/lib/libvpx.so.1.3 manually, instead of building a package for the old version. However, I can't do this for /usr/lib/libvpx.so and the bins, that perhaps aren't needed from the old package. $ pacman -Ql libvpx libvpx /usr/ libvpx /usr/bin/ libvpx /usr/bin/vp8_scalable_patterns libvpx /usr/bin/vp9_spatial_scalable_encoder libvpx /usr/bin/vpxdec libvpx /usr/bin/vpxenc libvpx /usr/include/ [snip] libvpx /usr/lib/ libvpx /usr/lib/libvpx.so libvpx /usr/lib/libvpx.so.1 libvpx /usr/lib/libvpx.so.1.3 libvpx /usr/lib/libvpx.so.1.3.0 libvpx /usr/lib/pkgconfig/ libvpx /usr/lib/pkgconfig/vpx.pc libvpx /usr/share/ [snip] $ ls -hlG /usr/lib/libvpx.so* lrwxrwxrwx 1 root 15 Dec 7 2013 /usr/lib/libvpx.so -> libvpx.so.1.3.0 lrwxrwxrwx 1 root 15 Dec 7 2013 /usr/lib/libvpx.so.1 -> libvpx.so.1.3.0 lrwxrwxrwx 1 root 15 Dec 7 2013 /usr/lib/libvpx.so.1.3 -> libvpx.so.1.3.0 -rwxr-xr-x 1 root 1.7M Dec 7 2013 /usr/lib/libvpx.so.1.3.0
On Fri, 24 Apr 2015 06:41:27 +0200, Ralf Mardorf wrote:
On Thu, 23 Apr 2015 22:56:56 +0300, Jesse Jaara wrote:
What you need to do is to create a custom package for the specific version of libvpx that doesn't conflict with the one from repo, so you can have both the new version for repo packages and the old version for whatever reason
Yes, I was thinking of simply installing the new package and copying /usr/lib/libvpx.so.1.3.0 from a backup and add the links /usr/lib/libvpx.so.1 /usr/lib/libvpx.so.1.3 manually, instead of building a package for the old version.
However, I can't do this for /usr/lib/libvpx.so and the bins, that perhaps aren't needed from the old package.
It works :). I wonder if there is a good reason to move the outdated lib and links from /usr/lib/ to /usr/local/lib? I prefer to have them in the same location. $ ls -hAl /usr/lib/libvpx* lrwxrwxrwx 1 root root 15 Apr 18 12:41 /usr/lib/libvpx.so -> libvpx.so.2.0.0 lrwxrwxrwx 1 root root 20 Apr 24 07:51 /usr/lib/libvpx.so.1 -> /lib/libvpx.so.1.3.0 lrwxrwxrwx 1 root root 20 Apr 24 07:51 /usr/lib/libvpx.so.1.3 -> /lib/libvpx.so.1.3.0 -rwxr-xr-x 1 root root 1.7M Dec 7 2013 /usr/lib/libvpx.so.1.3.0 lrwxrwxrwx 1 root root 15 Apr 18 12:41 /usr/lib/libvpx.so.2 -> libvpx.so.2.0.0 lrwxrwxrwx 1 root root 15 Apr 18 12:41 /usr/lib/libvpx.so.2.0 -> libvpx.so.2.0.0 -rwxr-xr-x 1 root root 2.0M Apr 18 12:41 /usr/lib/libvpx.so.2.0.0 Regards, Ralf
On Fri, Apr 24, 2015 at 8:06 AM, Ralf Mardorf
On Fri, 24 Apr 2015 06:41:27 +0200, Ralf Mardorf wrote:
On Thu, 23 Apr 2015 22:56:56 +0300, Jesse Jaara wrote:
What you need to do is to create a custom package for the specific version of libvpx that doesn't conflict with the one from repo, so you can have both the new version for repo packages and the old version for whatever reason
Yes, I was thinking of simply installing the new package and copying /usr/lib/libvpx.so.1.3.0 from a backup and add the links /usr/lib/libvpx.so.1 /usr/lib/libvpx.so.1.3 manually, instead of building a package for the old version.
However, I can't do this for /usr/lib/libvpx.so and the bins, that perhaps aren't needed from the old package.
It works :).
This is because of the so called SONAME. That is the name in a shared library that will be to look for it when it is used in a program. Usually, in standard linux packages the SONAME of a shared library includes only the major version number. For example, with the latest version: $ objdump -p /usr/lib/libvpx.so | grep SONAME SONAME libvpx.so.2 And with an old one, I assume: $ objdump -p /usr/lib/libvpx.so.1.3.0 | grep SONAME SONAME libvpx.so.1 You can check the SONAME used by VirtualBox with this command: $ objdump -p /usr/lib/virtualbox/components/VBoxC.so | grep vpx NEEDED libvpx.so.2 And check whether the file is found with: $ ldd /usr/lib/virtualbox/components/VBoxC.so | grep libvpx libvpx.so.2 => /usr/lib/libvpx.so.2 (0x00007f095d9e8000) The bottom line is that if the conflict is between different major version of the library, no problem: just copy "libvpx.so.1" to /usr/lib/ or /usr/local/lib/. The "libvpx.so" symbolic link exists because it will be the library name used to build new programs, but it is not needed in runtime. HTH -- Rodrigo
On Sat, 25 Apr 2015 10:01:57 +0200, Rodrigo Rivas wrote:
[snip] The "libvpx.so" symbolic link [snip] is not needed in runtime.
Thank you :).
participants (8)
-
Aaron Caffrey
-
G. Schlisio
-
Guus Snijders
-
Jesse Jaara
-
Mauro Santos
-
Ralf Mardorf
-
Rodrigo Rivas
-
Simon Hanna