August 2007 - Pacman-dev - lists.archlinux.org

Re: [pacman-dev] Database consistency checking
by Nagy Gabor 26 Aug '07

26 Aug '07

Well, I thought the following method (pseudocode) for (pkg in pkgcache) { pkgdup = alpm_pkg_dup(pkg); clean_requiredby(pkgdup); _alpm_pkg_update_requiredby(pkgdup); good = sort_then_compare_requiredby(pkg, pkgdup); alpm_pkg_free(pkgdup); } ------------- depend checking is similar, just use alpm_checkdeps for a list containing pkgdup only. ------------- Bye, ngaba PS: Sorry for replying your e-mail address earlier.

2 3

[pacman-dev] 3.1 release, pacman-git builds, etc.
by Dan McGee 25 Aug '07

25 Aug '07

I'll try to keep this short and sweet, and hopefully this wakes up the ghosts on the mailing list and we can make a push to get 3.1 released sometime in the relatively soon future. I've made a PKGBUILD that I threw together tonight to actually test pacman on my system without killing the working pacman 3.0.X install. It installs pacman and all its files to /usr/local, which is rather convenient for testing as you can just switch that directory in and out of your path as necessary. It also skips the complicated renames of files, and as a bonus, gives our autoconf script some testing with alternate install locations. However, it is configured to use your current db and cache at the /var location, so don't think that is necessarily safe (although it better be). Here is the most recent build as of when I am writing this email, use at your own risk! http://www.archlinux.org/~dan/pacman-git-3.1.0devel-2-i686.pkg.tar.gz http://www.archlinux.org/~dan/pacman-git_PKGBUILD With that said, I need your guys help testing this stuff out AND fixing the bugs and snags we hit that prevent us from releasing. The things on my list that definitely need to be done: * Ensure our config file changes are not necessary; e.g. old config files should mostly work with the new software. I fixed a few of these issues tonight. * General usability tests. Make sure things are acting as they should, no regressions, etc. * Merge the asciidoc branch and get our manpages up to snuff. * Figure out why Doxygen is generating some extra unnecessary manpages, and find a way to kill it. * makepkg testing. A lot of it, I haven't really used the new one at all since I tend to build official packages with the current release of makepkg to make sure it doesn't break things. * Translation updates. This could be a killer, but even if people don't get all the scripts translated we should try to get the pacman/libalpm translations back up to 100%. We lost a lot of messages because we cut debug translations, so that should help. * Testing of every bug on Flyspray marked "requires testing" and set to be fixed in 3.1. * Anything else you guys can think of. Please reply and post it and make sure it gets addressed. I've already got some ideas for 3.2/4.0 up my sleeve, but I'll put those in another email so we stay on topic here. And unless your idea is absolutely essential for a 3.1 release, try to keep them there as well. -Dan

4 8

[pacman-dev] FS#7308 implementation questions
by rprinse＠planet.nl 25 Aug '07

25 Aug '07

As I was browsing through the task list I stumbled upon FS#7308. This was a feature I also would like to have implemented so I thought why not try it myself! Because I'm lazy sometimes (who isn't) I don't always take care of any .pacnew or .pacsave files immediately so a nice timestamp suffix would prevent them from getting overwritten by pacman. Especially when you would like to see what changed overtime or when you just don't want that your old saved settings might get overwritten. So this is what i came up with: an AddDateSuffix directive in pacman.conf to enable this behaviour. If the option was enabled by the user add this timestamp suffix -YYYYMMDDHHMM (maybe even seconds??) right after .pac{new,save}. But while while going through some code I noticed the PATH_MAX constant, so can't we get in trouble if this is too small?? Flyspray link: http://bugs.archlinux.org/task/7308 I would really like to get some feedback, Thanks in advance, --DeliQ

3 4

[pacman-dev] hackish --ask option ?
by Xavier 24 Aug '07

24 Aug '07

Another interesting post from the forum : http://bbs.archlinux.org/viewtopic.php?id=35901 The documentation of the --ask option is quite funny indeed : --ask number Pre-specify answers to questions. It is doubtful whether this option even works, so I would not recommend using it. TODO: docu- ment this more, as I have no idea how it works or when you would use it, or if we should just dump it. I made an attempt of understanding what this option did, and then documenting it, but I doubt it's clear enough. I'm not sure what should be done here : 1) trying to document this option better 2) trying to implement this feature in a better way 3) just dropping it (not sure that's a good idea, since it's apparently useful in some cases). I think that's also low priority (ie not needed for 3.1), but feel free to comment on this issue.

3 4

[pacman-dev] Suggestion: Move local db to a different location
by Travis Willard 24 Aug '07

24 Aug '07

Here's a quick suggestion - far too many times I've seen people blow away their entire /var/lib/pacman/ folder in hopes of getting rid some error message or another, only to realize that pacman ALSO stores its locally-installed info there too and that they're now, essentially, screwed as far as pacman is concerned. Can we put this local info in a different place, or at least separate it from the remote db info a little more clearly? Like, for example, instead of the current set up of /var/lib/pacman/local /var/lib/pacman/current /var/lib/pacman/extra etc... we have /var/lib/pacman/local/ /var/lib/pacman/remote/current /var/lib/pacman/remote/extra etc... This structure, to me, makes more sense, since the "local" repo is a totally different beast from the remote repo info. This also allows the creation of a sync-able 'local' repo, like [local] http://localhost:8080/path/to/local/repo in pacman.conf without conflicting names. If nobody has any objections, I suppose I could hack a patch into the files backend that would do this, and possibly move from the current structure to the new one if it detects the old structure. In addition, those adventurous souls who like rm -r can be told to just rm -r /var/lib/pacman/remote and that will get rid of all remote repo information, which can be freshly obtained with pacman -Sy. I'm not trying to make it idiot-proof, but a clearer boundary between the local info, which should never be touched at the command line unless you really know what you're doing, and the remote stuff, that you can screw over until the cows come home and, in the end, just run pacman -Sy to get it all back. -- Travis

3 4

[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