- Pacman-dev - lists.archlinux.org

Re: [pacman-dev] sync_prepare clean-up III, TODO (fwd)
by Nagy Gabor 24 Jul '07

24 Jul '07

>That pactest doesn't look right, does it? Oh, yes; copy/paste (fix sync / local):-P I'm on holiday now, there is no linux machine here, but you can probably fix the pactest file; after reading the code: the corrected pactest file probably fails. Bye, ngaba

1 1

Re: [pacman-dev] Database consistency checking (fwd)
by Nagy Gabor 23 Jul '07

23 Jul '07

---------- Forwarded message ---------- Date: Mon, 23 Jul 2007 22:54:17 +0200 (CEST) From: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> To: Discussion list for pacman development <pacman-dev(a)archlinux.org> Subject: Re: [pacman-dev] Database consistency checking > The only thing that is worrying me is that ideally, depend and requiredby > checking would be done in the same time. There is no need to do every check > twice. You are right, but since this is a rarely used function, IMHO speed is not so important here (in my opinion: this function should be as simple as possible). Bye, ngaba

1 0

Re: [pacman-dev] [patch] sync_prepare clean-up I: 2in1 -Se bugfix (fwd)
by Nagy Gabor 23 Jul '07

23 Jul '07

---------- Forwarded message ---------- Date: Mon, 23 Jul 2007 22:52:09 +0200 (CEST) From: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> To: Discussion list for pacman development <pacman-dev(a)archlinux.org> Subject: Re: [pacman-dev] [patch] sync_prepare clean-up I: 2in1 -Se bugfix Hi! This is a nice patch! As I see (I couldn't test it), your test doesn't produce the same result as mine: change self.args to "-Se pkg1 pkg2" in my sync1002.py. However, I prefer your version, because that is faster. Bye, ngaba

1 0

[pacman-dev] Maelstrom(Pacman in C#) project brief
by Bozhidar Batsov 23 Jul '07

23 Jul '07

My implementation of pacman's functionality codenamed "Maelstrom" has reach a usable state. I actually managed to graduate thanks to it, as it was my graduation task, so now I'm an engineer from the Technical University of Sofia, Bulgaria. Currently my project supports most of pacman's capabilities + a few more, but I was thinking what is the community's opinion on the subject - is there any point in developing another pacman... I'd like to hear from you, because I was thinking to do a complete overhaul of Maelstrom to make it more sturdy and elegant and to release it to the general public, but maybe that will be pointless if no one thinks there is the need of another implementation of the package management system. Here are some finer points of the maelstrom project: 1. This is not a client for libaplm - it is a complete framework written from scratch without even consulting the original source code. It consists of a couple of libraries and two clients - one console app and one written in GTK#. Everything is 100% percent coded in C# 2.0. 2. Instead of the current db format - files hierarchy located under /var/lib/pacman, maelstrom relies of a RDBMS for it's bookkeeping, though it creates the entries in pacman's DB as well for backwards compatibility. 3. I can initially import in it's DB the current state of pacman's DB. 4, It understands the format of pacman.conf and parses it natively. Here are a couple of screenshots: ftp://78.128.17.199/sync.png ftp://78.128.17.199/refresh.png ftp://78.128.17.199/whirl.png

5 20

[pacman-dev] Pacman doesn't handle properly the multiple satisfiers, localdb corruption
by ngaba＠petra.hos.u-szeged.hu 21 Jul '07

21 Jul '07

Hi! Well, you probably will ask me to send patch, but I'm waiting for your decision. First, here is the problem: ===requiredby005.py== self.description = "Remove lp1, requiredby should move from lp1 to lp2" lp1 = pmpkg("foo") lp1.requiredby = ["pkg3"] self.addpkg2db("local", lp1) lp2 = pmpkg("pkg2") lp2.provides = ["foo"] self.addpkg2db("local", lp2) lp3 = pmpkg("pkg3") lp3.depends = ["foo"] self.addpkg2db("local", lp3) self.args = "-R %s" % lp1.name self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=foo") self.addrule("PKG_EXIST=pkg2") self.addrule("PKG_REQUIREDBY=pkg2|pkg3") ------------------------- This test fails and hence the database becomes corrupt: alpm_checkdeps is clever enough to let pacman remove foo, however update of pkg2's requiredby is missing after the remove. However, this is not a pactest to commit: as you see, pkg2's requiredby field is missing: this can happen, if pkg3 was the last installed package, because _alpm_trans_update_depends works in a "funny" way: it fills in the "literal" satisfier's requiredby only or _all_ "provider" satisfiers' requiredby. So, my question, how I fix this? How should we store multiple satisfiers in localdb? case 1: We find all satisfier package and fill in _all_ requiredby fields. case 2: We flag only one package as a satisfier with requiredby, and we handle properly these requiredby "moves". case 3: any other idea? We must choose one, because this is not defined in pacman now. I prefer case 1. Pros: -easy to implement (only _alpm_trans_update_depends needs patching) -by doing this, we clean up _alpm_trans_update_depends using alpm_depcmp -_alpm_pkg_update_requiredby prefers this way now -this won't break prepare/commit hierarchy (because alpm_checkdeps should somehow inform remove_commit in case 2) -when using -d switch, implement case 2 is difficult Contras: -slower!! (we need to check for providers always) -some users may have corrupted(?) localdb as shown in the pactest file (this is rare) -one satisfier is enough Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 17

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-326-gea9a756
by Dan McGee 20 Jul '07

20 Jul '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 ea9a756eeaca7398c0860b55f8abe2932ad195bd (commit) via 72c15482dcf3532c6b8a1458385f11d1a06177a0 (commit) via 0d00f7095f1f26b981747c678551436e2495c68e (commit) via b0c064d59b8786a1e169e305a263fc13e2d7ed32 (commit) via 5991e85abb22e32385f6925cf5a6db97a76623f7 (commit) via df2447cd237a8c17fbe7baf7c3e80d1d2db8f2a9 (commit) via 23a4d51b7a555ed24266417ba682944072912f53 (commit) via 88077889a4d16b56e9d9f60831d4e5d5d9a4ecb4 (commit) via 240bdf59713e85bc3d3a3335cf69c2bb9003369a (commit) via c68d3cc38a78a7eb80f88981ddfdc6db690038aa (commit) from 466d289e6a3e7dbaf567b39485c49d67eac5b362 (commit) - Log ----------------------------------------------------------------- commit ea9a756eeaca7398c0860b55f8abe2932ad195bd Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Fri Jul 20 01:22:45 2007 +0200 libalpm/conflict.c : cleanup + fix for conflict001. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 72c15482dcf3532c6b8a1458385f11d1a06177a0 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Fri Jul 20 01:20:16 2007 +0200 add conflict001 pactest. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 0d00f7095f1f26b981747c678551436e2495c68e Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Fri Jul 20 10:43:55 2007 +0200 libalpm/sync.c : two memleak fixes in _alpm_sync_prepare. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit b0c064d59b8786a1e169e305a263fc13e2d7ed32 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Fri Jul 20 10:22:36 2007 +0200 libalpm/sync.c : fix DEPENDSONLY flag handling. I didn't like the patch proposed by Nagy for the sync1002 pactest here: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008971.html So here is another attempt of fixing it. In case of the DEPENDSONLY flag : 1) pass an empty list to resolvedeps instead of the list of targets 2) empty the trans->packages targets list before adding the resolved deps. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 5991e85abb22e32385f6925cf5a6db97a76623f7 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Fri Jul 20 10:17:57 2007 +0200 Add sync1002 pactest. Reference: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008971.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit df2447cd237a8c17fbe7baf7c3e80d1d2db8f2a9 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Thu Jul 19 00:22:02 2007 +0200 libalpm/alpm_list.c : add SYMEXPORT to all alpm_list_ functions. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 23a4d51b7a555ed24266417ba682944072912f53 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jul 18 10:26:21 2007 -0400 Reorder functions in libalpm/package.c for Doxygen purposes Put all of the public functions at the top and inside the Doxygen packages group. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 88077889a4d16b56e9d9f60831d4e5d5d9a4ecb4 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Wed Jul 18 10:12:14 2007 -0400 Hungarian translation updates Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 240bdf59713e85bc3d3a3335cf69c2bb9003369a Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Mon Jul 16 18:27:42 2007 +0200 libalpm/deps.c : split alpm_depcmp. That function wasn't big, but this might be useful for later refactoring of the search for satisfier code. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit c68d3cc38a78a7eb80f88981ddfdc6db690038aa Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Tue Jul 17 14:23:18 2007 +0200 libalpm/deps.c : split sortbydeps function. The _alpm_sortbydeps function has two main part : 1) initialization of the graph structure 2) the sorting itself So it didn't seem bad to move the first part to a second function. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: lib/libalpm/alpm_list.c | 22 +- lib/libalpm/conflict.c | 249 +++++--------- lib/libalpm/deps.c | 113 ++++--- lib/libalpm/package.c | 827 +++++++++++++++++++++--------------------- lib/libalpm/sync.c | 36 +-- pactest/tests/conflict001.py | 19 + pactest/tests/sync1002.py | 19 + po/hu.po | 6 +- 8 files changed, 629 insertions(+), 662 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 466d289e6a3e7dbaf567b39485c49d67eac5b362 \ ea9a756eeaca7398c0860b55f8abe2932ad195bd

1 0

[pacman-dev] [patch] sync_prepare clean-up II, two memleak fixes
by Nagy Gabor 19 Jul '07

19 Jul '07

Hi! This patch requires the clean-up I patch to work properly. Bye, ngaba

1 0

[pacman-dev] alpm_list_* functions : public or private ?
by Xavier 19 Jul '07

19 Jul '07

The functions in alpm_list.c all start with alpm_list_, but some of them don't have SYMEXPORT. By reading the rest of the code, I assumed that : _alpm_* == private alpm_* == public (so with SYMEXPORT) Is this a real rule ? If so, should all functions in alpm_list.c be symexported, or should the ones without SYMEXPORT be renamed to _alpm_* ?

2 2

[pacman-dev] feature request: create .tar.gz package from an installed one
by ngaba＠petra.hos.u-szeged.hu 18 Jul '07

18 Jul '07

Hi! In my opinion one of the best thinks in pacman that unlike many other package managers user can undo lots of thinks (see -R group after -S group, -Rs after -S ...). However, user cannot undo a package upgrade, because most sync servers doesn't store old packages. So I think that it would be very useful, if there would be a pacman or makepkg command to create a package from an installed one (or is this implemented?). We could(?) do this from the local db and the installed files. Of course this wouldn't be a "distro" package, because config files can change etc. but this is even better for backup/undo. You may say, that this is totally useless, because if a package is installed then there must exist a proper .tar.gz file somewhere. -but package can be installed from aur and user may deleted the "binary" file -if you move to a place with no network, you can easily create "backup" packages before -R (and reinstall) or you can give this package to your Archer friend -slightly reduces needless Arch-server using -it can be easily implemented (IMHO) Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

5 7

[pacman-dev] [patch] some Hungarian translation fixes
by ngaba＠petra.hos.u-szeged.hu 18 Jul '07

18 Jul '07

Hi! I attached the patch. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 3