- Pacman-dev - lists.archlinux.org

[pacman-dev] feature request: pacman lock file
by Thomas Bächler 23 Aug '07

23 Aug '07

I have several chroot environments that all use pacman as their package manager. I use a shared /tmp directory between them, so that X applications and some other things work across the chroots. This however is a problem with pacman, since pacman puts its lock file in /tmp/, which means I cannot use pacman simultaneously in these chroots. It would IMO be a better idea to put the lock file in /var/lib/pacman/ instead, which ensures that the lock file and the pacman database are always tied together.

3 4

Re: [pacman-dev] makepkg symlink dereference issue (was: 3.1 release, pacman-git builds, etc.)
by Dan McGee 23 Aug '07

23 Aug '07

On 8/23/07, Xavier <shiningxc(a)gmail.com> wrote: > On Wed, Aug 22, 2007 at 06:13:16AM +0100, Andrew Fyfe wrote: > > I've built quite a few packages with makepkg-3.1 and it appears to be > > working ok :) > > > > I thought it worked since I first tried it on pacman-git PKGBUILD. > But it actually fails with most PKGBUILDs using source tarballs. > > > >From 223d5606cab31c8695b9516ba21434da5529dedf Mon Sep 17 00:00:00 2001 > From: Chantry Xavier <shiningxc(a)gmail.com> > Date: Thu, 23 Aug 2007 20:00:41 +0200 > Subject: [PATCH] makepkg : add -L (--dereference) to file. > > makepkg didn't correctly detect the type of the archive > since it didn't dereference symlinks, and so failed > to extract the source tarball. > > Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Pulled this, thanks. -Dan

1 0

[pacman-dev] MD5/SHA* why?
by Andrew Fyfe 23 Aug '07

23 Aug '07

I asked this question a while ago about makepkg now I'm asking about pacman... why do we need support for multiple checksum types? What's wrong with md5? Andrew

10 28

[pacman-dev] Outdated comments in sync.c code ?
by Xavier 22 Aug '07

22 Aug '07

First this one: 515 /* hmmm, depend.name isn't installed, so it must be conflicting 516 * with another package in our final list. For example: 517 * 518 * pacman -S blackbox xfree86 519 * 520 * If no x-servers are installed and blackbox pulls in xorg, then 521 * xorg and xfree86 will conflict with each other. In this case, 522 * we should follow the user's preference and rip xorg out of final, 523 * opting for xfree86 instead. 524 */ 525 526 /* figure out which one was requested in targets. If they both 527 * were, then it's still an unresolvable conflict. */ I don't get it. Since xfree86 is already in the target, why would blackbox pull xorg ? That's not what the code does, but maybe it did before (I only tried git and cvs) ? If the following pactest is correct, then this comment doesn't apply anymore : self.description = "Choose provider in the targets first" sp1 = pmpkg("blackbox") sp1.depends = ["x-server"] self.addpkg2db("sync", sp1) sp2 = pmpkg("xfree86") sp2.provides = ["x-server"] self.addpkg2db("sync", sp2) sp3 = pmpkg("xorg") sp3.provides = ["x-server"] sp3.conflicts = ["xfree86"] self.addpkg2db("sync", sp3) self.args = "-S blackbox xfree86" self.addrule("PACMAN_RETCODE=0") self.addrule("PKG_EXIST=blackbox") self.addrule("PKG_EXIST=xfree86") self.addrule("!PKG_EXIST=xorg") This one is even worse, I don't understand it at all : 638 /* XXX: this fails for cases where a requested package wants 639 * a dependency that conflicts with an older version of 640 * the package. It will be removed from final, and the user 641 * has to re-request it to get it installed properly. 642 * 643 * Not gonna happen very often, but should be dealt with... 644 */ I still tried to do a pactest following the instructions, and this works fine as well (git and cvs) : self.description = "A dep conflicts with older version of package" sp1 = pmpkg("pkg1", "1.0-2") sp1.depends = ["pkg2=1.0-2"] self.addpkg2db("sync", sp1) sp2 = pmpkg("pkg2", "1.0-2") sp2.conflicts = [ "pkg1=1.0-1" ] self.addpkg2db("sync", sp2) lp1 = pmpkg("pkg1", "1.0-1") lp1.depends = ["pkg2=1.0-1"] self.addpkg2db("local", lp1) lp2 = pmpkg("pkg2", "1.0-1") lp2.requiredby = [ "pkg1" ] self.addpkg2db("local", lp2) self.args = "-S pkg1" self.addrule("PACMAN_RETCODE=0") self.addrule("PKG_EXIST=pkg1") self.addrule("PKG_VERSION=pkg1|1.0-2") self.addrule("PKG_EXIST=pkg2") self.addrule("PKG_VERSION=pkg2|1.0-2")

2 2

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-358-ge24bcc3
by Dan McGee 22 Aug '07

22 Aug '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via e24bcc395e7da2a4f46933ea342d0ce90b708de4 (commit) via 515754faacf9dd33b94e6e5a17ca04d27d61f482 (commit) via d09d114e99c29d1392c546a6553650ecde5138fc (commit) via c22e381a8b86412b6c181446128affe32ab1d71e (commit) from 13525255dcd257e69d7c246bf32ceb263fbc31b9 (commit) - Log ----------------------------------------------------------------- commit e24bcc395e7da2a4f46933ea342d0ce90b708de4 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Aug 21 23:34:32 2007 -0400 configure.ac: Remove the hyphen from the version suffix Also switch out outdated PACKAGE_STRING variable for pacman_display_version. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 515754faacf9dd33b94e6e5a17ca04d27d61f482 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Aug 21 23:29:10 2007 -0400 Various valgrind mem leak fixes Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d09d114e99c29d1392c546a6553650ecde5138fc Author: Dan McGee <dan(a)archlinux.org> Date: Tue Aug 21 21:53:38 2007 -0400 Add a default cachedir if one wasn't specified Use the default cachedir (specified at compile time) if one wasn't specified on the command line or in the config file. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit c22e381a8b86412b6c181446128affe32ab1d71e Author: Dan McGee <dan(a)archlinux.org> Date: Tue Aug 21 21:28:05 2007 -0400 Post trial install changes, round one A bunch of changes related to my first "real" install of pacman-git into /usr/local and trying to use it. * Shift some uses of free -> FREE in libalpm. * Move stat and sanity checks of config paths into libalpm from the config and argument parsing in pacman.c. * Fix issue where dbpath still was not defined early enough due to its requirement for being used in alpm_db_register. This should be rewritten so it doesn't have this dependency, but this will work for now. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: configure.ac | 4 +- lib/libalpm/alpm.h | 13 ++-- lib/libalpm/cache.c | 1 + lib/libalpm/conflict.c | 2 +- lib/libalpm/db.c | 60 ++++++++-------- lib/libalpm/db.h | 1 - lib/libalpm/deps.c | 8 +- lib/libalpm/error.c | 2 + lib/libalpm/handle.c | 182 ++++++++++++++++++++++++++++++++---------------- lib/libalpm/package.c | 2 +- lib/libalpm/server.c | 18 ++++-- lib/libalpm/sync.c | 8 +- lib/libalpm/trans.c | 2 +- lib/libalpm/util.c | 2 +- src/pacman/Makefile.am | 2 + src/pacman/conf.c | 4 + src/pacman/conf.h | 9 ++- src/pacman/pacman.c | 107 ++++++++++++++-------------- 18 files changed, 258 insertions(+), 169 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 13525255dcd257e69d7c246bf32ceb263fbc31b9 \ e24bcc395e7da2a4f46933ea342d0ce90b708de4

1 0

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-354-g1352525
by Dan McGee 21 Aug '07

21 Aug '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 13525255dcd257e69d7c246bf32ceb263fbc31b9 (commit) via b1808930ce45a034981626fc20bbc7920890899e (commit) via 17d9122e01f5a675f4c7882e68ceae65aae7b5aa (commit) via 942175feaa866c4e536a7da0f77ab54de98b6c07 (commit) via 3acbf56bbab128d8ef037a7dcc87d91fe7354d14 (commit) from f81e619974ca47f6dba8c3002577447a71e0f1ec (commit) - Log ----------------------------------------------------------------- commit 13525255dcd257e69d7c246bf32ceb263fbc31b9 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Wed Jul 25 14:47:46 2007 +0200 Add sync1003 pactest. The sync package pkg3 depends on the sync package pkg2, but pkg1 replaces pkg2. So pkg2 is added to the remove list. When checkdeps checks if pkg2 can be removed, it looks at the packages that require pkg2 (with the RequiredBy field of pkg2), but this doesn't contain pkg3 at this point. RequiredBy fields are only updated after the packages are installed. Proposed solution : checkdeps should know both the remove and upgrade list to decide properly. Reference: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008972.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit b1808930ce45a034981626fc20bbc7920890899e Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Mon Jul 16 20:58:58 2007 +0200 libalpm/add.c,trans.c : cleanup of requiredby handling. This patch cleans up and fix the _alpm_trans_update_depends function and ensure that all requiredby fields are filled in case of multiple satisfiers (previously, the handling of mutliple satisfiers in that function was inconsistent). This makes a special case handling of requiredby in commit_single_pkg() obsolete, and so allows cleaning that code as well. Also fixed upgrade056 pactest because : 1) the requiredby fields were wrong, and this wouldn't happen with the fixed _alpm_trans_update_depends(). 2) this is a very unusual case anyway (and handling all corner cases combined to a broken database seems nearly impossible to achieve). References : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008919.html http://www.archlinux.org/pipermail/pacman-dev/2007-July/008920.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 17d9122e01f5a675f4c7882e68ceae65aae7b5aa Author: Dan McGee <dan(a)archlinux.org> Date: Mon Aug 20 13:28:51 2007 -0400 Fix for FS 6404 and functionalize some cachedir handling stuff In order to best resolve bug 6404, move some cachedir handling stuff out of sync.c and into util.c and create two new functions: filecache_find and filecache_setup. sync.c was rewritten to use these, and alpm_fetch_pkgurl now also uses these routines. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 942175feaa866c4e536a7da0f77ab54de98b6c07 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Aug 20 12:55:38 2007 -0400 Add const qualifier to md5_file and alpm_get_md5sum Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3acbf56bbab128d8ef037a7dcc87d91fe7354d14 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Aug 20 00:38:37 2007 -0400 Clean up architecture handling in configure.ac Remove the need for two variables for the architecture-specific switches (things like "-march=i686") by combining it into one variable. Also allow configure to proceed with only a warning if we don't have presets for the detected architecture- it is kind of stupid to restrict ourselves like we had been. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: configure.ac | 31 +++++------ etc/makepkg.conf.in | 4 +- lib/libalpm/add.c | 37 ------------- lib/libalpm/alpm.h | 2 +- lib/libalpm/md5.c | 6 ++- lib/libalpm/md5.h | 2 +- lib/libalpm/package.c | 19 +++---- lib/libalpm/server.c | 68 +++++++++++------------- lib/libalpm/server.h | 2 - lib/libalpm/sync.c | 123 +++++++++++-------------------------------- lib/libalpm/trans.c | 73 ++++--------------------- lib/libalpm/util.c | 73 ++++++++++++++++++++++++-- lib/libalpm/util.h | 2 + pactest/tests/sync1003.py | 26 +++++++++ pactest/tests/upgrade056.py | 1 + 15 files changed, 202 insertions(+), 267 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ f81e619974ca47f6dba8c3002577447a71e0f1ec \ 13525255dcd257e69d7c246bf32ceb263fbc31b9

1 0

[pacman-dev] dangerous symlink handling with --root option
by Mister Dobalina 21 Aug '07

21 Aug '07

Hi again, (and sorry again for any split lines) Okay, so I was fooling around with the --root option again, and after I realized from one of Xavier's posts that pre/post install scriptlets won't be run at all until /bin/sh (from bash) is installed, I figured I should install the packages twice. This led to two issues. I have a bash script (attached) that basically does: pkglist=( ... bunch o' base packages ... ) mkdir /tmp/pacman.test pacman -U --root /tmp/pacman.test ${pkglist[*]} pacman -U --root /tmp/pacman.test ${pkglist[*]} The second install of coreutils causes: error: cannot remove file '/tmp/pacman.test/usr/bin/sleep': Read-only file system error: failed to commit transaction (transaction aborted) error: failed to release transaction (could not commit transaction) First Issue: CPU usage then goes to 100%, so I assume that pacman has gone into an infinite loop somewhere. Second Issue: the real concern is the "Read-only file system" error, since /tmp is on a tmpfs and is definitely not read-only. My / partition is read-only though, and # ls -l /tmp/pacman.test/usr/bin/sleep lrwxrwxrwx 1 root root 10 2007-08-16 16:13 /tmp/pacman.test/usr/bin/sleep -> /bin/sleep So pacman was following the absolute symlink *out* of the --root and trying to remove /bin/sleep from my main arch install ?? Cheers, Jeremy Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca

2 6

[pacman-dev] tmp permissions problem is back?
by Mister Dobalina 20 Aug '07

20 Aug '07

See below. Sorry for any split command lines, should be obvious where they are... cheers, Jeremy # pacman -Q pacman libarchive pacman 3.0.5-3 libarchive 2.2.6-1 # mkdir /tmp/pacman.test # pacman -Ud /var/cache/pacman/pkg/filesystem-2007.08-1.pkg.tar.gz --root /tmp/pacman.test # ls -l /tmp/pacman.test total 0 drwxr-xr-x 2 root root 40 2007-07-30 15:52 bin/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 boot/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 dev/ drwxr-xr-x 4 root root 440 2007-07-30 15:52 etc/ drwxr-xr-x 3 root root 60 2007-07-30 15:52 home/ drwxr-xr-x 3 root root 60 2007-07-30 15:52 lib/ drwxr-xr-x 5 root root 100 2007-07-30 15:52 mnt/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 opt/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 proc/ drwxr-x--- 2 root root 40 2007-07-30 15:52 root/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 sbin/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 srv/ drwxr-xr-x 2 root root 40 2007-07-30 15:52 sys/ drwxr-xr-x 2 root root 40 2007-08-20 12:09 tmp/ drwxr-xr-x 10 root root 220 2007-07-30 15:52 usr/ drwxr-xr-x 13 root root 280 2007-08-20 12:09 var/ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca

3 8

[pacman-dev] difficult symlink puzzle, part 2.
by Nagy Gabor 20 Aug '07

20 Aug '07

Hi! If I didn't misunderstood conflict.c then fileconflict check fails in the following case (pacman -A pkg1 pkg2): pkg1 contains: /dir1/file pkg2 contains: /dir2/file, if /dir1 and /dir2 exists on filesystem, and /dir2 is a symlink pointing to /dir1. Much more difficult problem (and fortunately much rarer), if pkg2 creates the /dir2 symlink, so it didn't exist before the transaction. Any tests/feedbacks appreciated... How is this handled in other package managers? Bye, ngaba PS: a possible semi-solution: pacman shouldn't stop/overwrite in case of these "hidden" fileconflict errors, it extract /dir2/file as /dir2/file.pkg2.pacnew and do something at the end of the transaction. (Speed is a big limiting factor here.)

4 3

[pacman-dev] "FATAL: kernel too old" error message during upgrade
by Roman Kyrylych 20 Aug '07

20 Aug '07

Hi! One of our local community members is getting this output when doing -Syu after installing 0.7.2: checking package integrity... done. cleaning up... done. (8/8) checking for file conflicts [#####################] 100% (1/8) installing kernel-headers [#####################] 100% (2/8) upgrading glibc [#####################] 100% FATAL: kernel too old (3/8) installing binutils [#####################] 100% (4/8) installing gcc [#####################] 100% (5/8) installing db [#####################] 100% (6/8) installing gdbm [#####################] 100% (7/8) upgrading openssl [#####################] 100% (8/8) installing python [#####################] 100% FATAL: kernel too old FATAL: kernel too old Any ideas what causes this? -- Roman Kyrylych (Роман Кирилич)

3 6