[pacman-dev] libarchive issue
Upgrading to the last libarchive fixed some problems, but also caused a new one : http://bugs.archlinux.org/task/7484 I tried to look at it, since Dan was away, but miserably failed. I'm afraid this one is way too hard for me, I found all libarchive related stuff very confusing, and couldn't make any sense of it. All that is left is even more questions. Sorry about that :( Maybe I'll keep trying, if we can take the time to fix this, and if no one else can figure it out. The main questions I've (already in the bug comments) are : 1) why pacman got permission of /tmp wrong with old libarchive, while old bsdtar gets them right? 2) is the ARCHIVE_EXTRACT_NO_OVERWRITE option the only way in libarchive to avoid losing symlinks ? And does this option do what we want? I'm afraid both questions require some investigations for being answered.
Am Dienstag, 26. Juni 2007 20:38:24 schrieb Xavier:
Upgrading to the last libarchive fixed some problems, but also caused a new one : http://bugs.archlinux.org/task/7484
I tried to look at it, since Dan was away, but miserably failed. I'm afraid this one is way too hard for me, I found all libarchive related stuff very confusing, and couldn't make any sense of it. All that is left is even more questions. Sorry about that :( Maybe I'll keep trying, if we can take the time to fix this, and if no one else can figure it out.
The main questions I've (already in the bug comments) are : 1) why pacman got permission of /tmp wrong with old libarchive, while old bsdtar gets them right? 2) is the ARCHIVE_EXTRACT_NO_OVERWRITE option the only way in libarchive to avoid losing symlinks ? And does this option do what we want?
I'm afraid both questions require some investigations for being answered.
Does anybody know if this might be fixed soon? This bug breaks a php installation when installing any extension module. php`s own modules are installed into /usr/lib/php/extensions/no-debug-non-zts-20060613 where that last dir is variable. So every additional extension is installed into /usr/lib/php/extensions/php which is a symlink to the first one. But if you install such an extension wit new pacman it overwrites the symlink and creates a new dir "php". The result ist: php does not find its own extensions anymore. So I would like to know if this take some time to solve; I`ll have to find some workaround then. Pierre -- archlinux.de
Am Mittwoch, 27. Juni 2007 10:07:54 schrieb Pierre Schmitz:
So I would like to know if this take some time to solve; I`ll have to find some workaround then.
OK, I have just rebuild all php modules. At next I have to decide wether I release a new php package or just ask the users to reinstall it. (the link has to be recreated) -- archlinux.de
2007/6/27, Pierre Schmitz <pierre@archlinux.de>:
So I would like to know if this take some time to solve; I`ll have to find some workaround then.
It would be nice to fix this issue, but it isn't easy. Every time something is fixed, it breaks something else. I found a way to fix it like I said in the bug report, but it could very well cause bugs much worse than the current one... And there are quite lot of different situations to consider, which doesn't make testing easier. I also don't want to cause major breakage (fortunately, I don't have the power to do so ;) ), so I hoped someone with more experiences and skills would look into that bug. Anyway, I'm still trying to understand libarchive better..
2007/6/26, Xavier <shiningxc@gmail.com>:
1) why pacman got permission of /tmp wrong with old libarchive, while old bsdtar gets them right?
I can already answer this : it's caused by backup files. When pacman extracts the filesystem package, it also extracts all backup files to /tmp/alpm_XXXXXX first for checking the md5sum. By removing this step, pacman gets the /tmp permission right, even when compiled against libarchive 1.3.1 , just like bsdtar 1.3.1 :) If we could somehow avoid extracting to real files, just for getting the md5sum, we should get a decent behavior from pacman with libarchive 1.3.1. But since libarchive 2.2.3 takes care of this case, it possibly has other improvement as well, so it's maybe still better to figure out how to use it correctly. I'm just glad I finally understood something (even if only partially : I don't know what libarchive 2.2.3 does for handling this case that libarchive 1.3.1 didn't).
participants (2)
-
Pierre Schmitz
-
Xavier