- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH 2/3] libalpm/deps.c : export _alpm_checkdeps (-> alpm_checkdeps).
by Chantry Xavier 26 Aug '07

26 Aug '07

2 1

[pacman-dev] [PATCH 1/3] libalpm/package.c : add new alpm_pkg_compute_requiredby function.
by Chantry Xavier 26 Aug '07

26 Aug '07

Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> --- lib/libalpm/alpm.h | 1 + lib/libalpm/package.c | 85 +++++++++++++++++++++++++++---------------------- 2 files changed, 48 insertions(+), 38 deletions(-)

1 0

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