- Pacman-dev - lists.archlinux.org

Re: [pacman-dev] [arch-dev-public] Fwd: [arch] circular dependence in core
by Xavier 01 Nov '07

01 Nov '07

On Thu, Nov 01, 2007 at 06:17:31PM +0200, Roman Kyrylych wrote: > 2007/11/1, Roman Kyrylych <roman.kyrylych(a)gmail.com>: > > 2007/11/1, Aaron Griffin <aaronmgriffin(a)gmail.com>: > > > Forwarding to the dev list in case people don't read the arch list. > > > > > > ---------- Forwarded message ---------- > > > From: Mister Dobalina <reebydobalina(a)yahoo.ca> > > > Date: Nov 1, 2007 10:27 AM > > > Subject: [arch] circular dependence in core > > > To: General Discusson about Arch Linux <arch(a)archlinux.org> > > > > > > > > > coreutils 6.9-3 -> depends on bash > > > > > > bash 3.2.025-1 -> depends on readline>=5.2 > > > > > > readline 5.2-4 -> depends on ncurses > > > > > > ncurses 5.6-4 -> depends on coreutils -> oops! > > > > > > > This was casused by this commit: > > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/ncurses/PKGBUILD.diff?r1=… > > I think we should revert it (because dependencies of other packages > > are fine and make more sense). > > > > And it was ncurses-5.6-4 package release that broke it. > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/ncurses/PKGBUILD.diff?r1=… > And we all missed this because pacman didn't complain when upgrading. > Well, no, this doesn't prevent pacman from installing the packages, only from sorting them, which is usually not critical. So pacman only prints a little warning in the --debug output when it detects a loop while sorting the packages, but that's all. Something like "dependency cycle detected" I don't know if this message should always be printed, on standard pacman output. There could maybe be a pacman option or an external tool for detecting dependencies cycles.

2 1

[pacman-dev] libalpm data structures
by Nagy Gabor 01 Nov '07

01 Nov '07

Hi! This is discussion-only (==no-patch) e-mail, mainly about code clean-up, so if you don't like that type of e-mails, please skip this. Xavier's compute_requiredby catch was the motivation of this e-mail: I never liked the following method: pmdepend_t *dep = alpm_splitdep(depend) /* char -> pmdepend_t conversion */ ...alpm_depcmp(pkg, dep)... FREE(dep) /* usually forgotten */ So I asked myself: Do we really need pmdepend_t struct? Why don't we use it in alpm_depcmp only ("internally")? So the depend-input of alpm_depcmp could be char* (and pmdepend_t should be disappear from libalpm API). Then I read the .h files of libalpm. My impressions: 1. We don't need pmdepend_t => pmdepmod_t. See above. This is mainly used in pmdepmissing_t which is used to collect missing dependencies (pmdepmissing_t is not needed here neither), and to print error/log messages (usually pmdepend_t -> char conversion is done here, too); where we could also use char. 2. We have pmconflict_t. Nice. So we don't need pmdeptype_t (in pmdepmissing_t). As we discussed with Xavier, pmconflict_t should be a symmetric structure: {target,ctarget} set [<=> alpm_strcmp ordered (target, ctarget) pair] instead of (target,ctarget) ordered pair) <- this is a pmconflict_t-helper-function problem only. Future plans: 3. I still want to kill pmsyncpkg_t => pmsynctype_t (the ugliest data struct of libalpm) 4. If my preferred universal transaction becomes true, we won't need pmtranstype_t. And of course, if we rip off some unneeded structures, we also rip off tons of unneeded associated helper functions. Personally, I want to make a patch for 1. and 2. So if you don't like the idea, let me know. However, I'm a bit unsure in 2.: should I keep target and ctarget as char, or I should use pmpkg_t* instead <- faster but more "dangerous". Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

5 24

[pacman-dev] [PATCH] Add support for arch='all' to makepkg
by Roman Kyrylych 31 Oct '07

31 Oct '07

Hi! Today I have started adding support for noarch packages. This is the first step. The attached patch adds support for arch='all' to makepkg. It's very simple because it just sets CARCH to all and then everything else goes as usual. When we'll add support for subpackages - we'll have to make additional checks to be sure we can build -i686/-x86_64 package and -all package from one PKGBUILD. This depends on a way we implement subpackages and can be modified later. So far, pacman-git is able to install packages built with the modified makepkg, and shows "Architecture: all" on -Qi. I'll post patches for other scripts soon. How to test it: 1) get any font/cursor/etc PKGBUILD from AUR, 2) replace arch=('i686' 'x86_64') with arch='all' 3) use the patched makepkg to build the package 4) use pacman -U (git version, 3.0.x fails) to install the package 5) do pacman -Qi -- Roman Kyrylych (Роман Кирилич)

4 12

[pacman-dev] Conflicts handling
by Xavier 31 Oct '07

31 Oct '07

The pending patch [1] from Nagy for conflicts handling broke the following pactests : sync040, sync041, sync990 These pactests are "target vs target" conflicts that pacman doesn't try to resolve, and just stops. Nagy's patch tried to resolve these conflicts by removing one of the two conflicting targets. So that broke the 3 pactests above. When trying to change the code slightly to make pacman fail in this target-target case, the 3 pactests above now succeed, but it breaks 5 others : sync893, sync897, sync898, sync992, sync999 These pactests are actually other kinds of target vs target conflicts. So finally, pacman tries to auto-resolve these conflicts more often than not, instead of just failing. That's what I failed to see earlier, that there were different cases to consider. Now I see at least 4 kinds of target-target conflicts. I'm attaching 4 pactests to illustrate that. In my opinion, pacman could always fail with these target-target conflicts. This kind of conlicts is very rare (it doesn't make any sense to install two conflicting targets). However it can happen in an odd situation (see bug 7415), where a group is splitted across several repos. But pacman's behavior in this case is very odd anyway.. So I think it wouldn't be worse if pacman just failed, and so it would be left to the user to fix it manually, by removing the conflicting package from the targets, for example using --ignore. So this would give both a more coherent behavior, and cleaner code. If that's alright, I will try to edit (correctly this time) Nagy's patch to behave like that. But the 5 pactests listed above will then have to be edited accordingly (mostly changing PACMAN_RETCODE from 0 to 1). [1] http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html

2 2

[pacman-dev] [GIT] The official pacman repository branch, master now at v3.0.0-505-gccdf29f
by Dan McGee 31 Oct '07

31 Oct '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 ccdf29ffa8436d3cd5409b0d02287207716cf397 (commit) via ac79135b94b1cd2c3fc4818bdfbe8ec63a6166b6 (commit) via 6aeda5fbff1969befa322ef7b79664f13dea1d18 (commit) via be387148c95ee5ed4e45dc841cd12fee010b998a (commit) via 6af7dbcf72b0e95f7c36b17fac88fd2658c2a8e4 (commit) via aea45a8b20c786358cfe782b4e3ac37c7d9dbe37 (commit) via dede5371e7c11ceb6ea36ba770672d61aa9b9002 (commit) via 74aa54a1f6db109311e9bdc8cae64a2a26a2b860 (commit) via 014306eb99c90c5c5c6d19d50aa47e29c25e8e14 (commit) via c50a7c6026e491771f0607d5e3fed737b3b5e8f3 (commit) via 6cf8a5137e9e0a8fcdf5287187935ffc505a2132 (commit) via cc754bc6e3be0f37ca0eaca4b6b90f033433fb1a (commit) via fe3a461703a5d90937c0c6f1ce0c3d802c0f8630 (commit) from 671224b64c9478644125deec1496a27e8f579da9 (commit) - Log ----------------------------------------------------------------- commit ccdf29ffa8436d3cd5409b0d02287207716cf397 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Oct 30 08:12:09 2007 -0500 abs: prefer csup to cvsup Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ac79135b94b1cd2c3fc4818bdfbe8ec63a6166b6 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Oct 30 00:20:18 2007 -0500 Pick best python program available for 'make check' Use an autoconf macro to find us a python executable, preferring python2.5 if we can find it. From there, fall back to python2.4 and then python. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 6aeda5fbff1969befa322ef7b79664f13dea1d18 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 23:32:58 2007 -0500 When printing size_t, use %zd %d was used, which worked for Linux and FreeBSD. Not so for Darwin. The warning was probably spat out when compiling on x68_64 as well, but no developers use this architecture as their primary one. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit be387148c95ee5ed4e45dc841cd12fee010b998a Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 23:12:37 2007 -0500 libalpm/handle.c: make realpath() call portable BSD didn't support the NULL second argument GNU extension, so do it the old fashioned way. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 6af7dbcf72b0e95f7c36b17fac88fd2658c2a8e4 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 23:11:49 2007 -0500 pacman/query.c: add missing free() Signed-off-by: Dan McGee <dan(a)archlinux.org> commit aea45a8b20c786358cfe782b4e3ac37c7d9dbe37 Author: Scott Horowitz <stonecrest(a)gmail.com> Date: Mon Oct 29 21:25:30 2007 -0600 Small updates to documentation. Signed-off-by: Scott Horowitz <stonecrest(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit dede5371e7c11ceb6ea36ba770672d61aa9b9002 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 21:06:13 2007 -0500 Copy pmdelta_t objects in _alpm_pkg_dup() This was forgotten in the original set of patches. CC: Nathan Jones <nathanj(a)insightbb.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 74aa54a1f6db109311e9bdc8cae64a2a26a2b860 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 21:03:41 2007 -0500 Make general list copy function Package dup needs to copy all members. Nathan had his implementation, but I generalized it to this new alpm_list function (and will use it in the next commit). CC: Nathan Jones <nathanj(a)insightbb.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 014306eb99c90c5c5c6d19d50aa47e29c25e8e14 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Oct 28 13:39:12 2007 +0100 simple pactest renaming : split conflict* into depconflict* and fileconflict*. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit c50a7c6026e491771f0607d5e3fed737b3b5e8f3 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 07:13:58 2007 -0500 doxygen: preprocess SYMHIDDEN/SYMEXPORT macros so they don't show in docs Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 6cf8a5137e9e0a8fcdf5287187935ffc505a2132 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 01:28:13 2007 -0500 libalpm/delta: add const to most methods Signed-off-by: Dan McGee <dan(a)archlinux.org> commit cc754bc6e3be0f37ca0eaca4b6b90f033433fb1a Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 01:00:52 2007 -0500 libalpm: introduce MALLOC and CALLOC macros These macros take the place of the common 4 or 5 line blocks of code we had in most places that called malloc or calloc. This should reduce some code duplication and make memory allocation more standard in libalpm. Highlights: * Note that the MALLOC macro actually uses calloc, this is just for safety so that memory is initialized to 0. This can be easily changed in one place. * One malloc call was completely eliminated- it made more sense to do it on the stack. * The use of RET_ERR in public functions (mainly the alpm_*_new functions) was standardized, this makes sense so pm_errno is set. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit fe3a461703a5d90937c0c6f1ce0c3d802c0f8630 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Oct 29 00:01:17 2007 -0500 Add some more debugging output to dep checking code Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: Makefile.am | 2 +- configure.ac | 3 +- doc/Doxyfile | 6 +- doc/PKGBUILD.5.txt | 76 +++++++++++++++++-- doc/makepkg.8.txt | 18 ++++-- lib/libalpm/alpm.h | 8 +- lib/libalpm/alpm_list.c | 26 ++++++- lib/libalpm/alpm_list.h | 1 + lib/libalpm/conflict.c | 9 +-- lib/libalpm/db.c | 13 +--- lib/libalpm/delta.c | 11 ++-- lib/libalpm/deps.c | 33 ++++----- lib/libalpm/group.c | 7 +-- lib/libalpm/handle.c | 14 +--- lib/libalpm/package.c | 21 ++---- lib/libalpm/server.c | 12 +--- lib/libalpm/sync.c | 20 +++--- lib/libalpm/trans.c | 5 +- lib/libalpm/util.h | 7 ++- .../tests/{conflict004.py => depconflict100.py} | 0 .../tests/{conflict002.py => depconflict110.py} | 0 .../tests/{conflict003.py => depconflict111.py} | 2 +- .../tests/{conflict001.py => depconflict120.py} | 0 .../tests/{conflict005.py => fileconflict001.py} | 0 .../tests/{conflict006.py => fileconflict002.py} | 1 - scripts/abs.sh.in | 10 ++-- src/pacman/callback.c | 3 +- src/pacman/conf.c | 3 +- src/pacman/query.c | 3 +- 29 files changed, 182 insertions(+), 132 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 671224b64c9478644125deec1496a27e8f579da9 \ ccdf29ffa8436d3cd5409b0d02287207716cf397

1 0

[pacman-dev] [PATCH] Copy pmdelta_t objects in _alpm_pkg_dup().
by Nathan Jones 30 Oct '07

30 Oct '07

_alpm_pkg_dup() should create copies of all objects inside the pmpkg_t struct. I missed this function when adding the delta list to pmpkg_t. Signed-off-by: Nathan Jones <nathanj(a)insightbb.com> --- lib/libalpm/package.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c index 4f6f5a9..7829d48 100644 --- a/lib/libalpm/package.c +++ b/lib/libalpm/package.c @@ -49,6 +49,7 @@ #include "provide.h" #include "handle.h" #include "alpm.h" +#include "delta.h" /** \addtogroup alpm_packages Package Functions * @brief Functions to manipulate libalpm packages @@ -689,6 +690,7 @@ pmpkg_t *_alpm_pkg_new(const char *name, const char *version) pmpkg_t *_alpm_pkg_dup(pmpkg_t *pkg) { pmpkg_t* newpkg; + alpm_list_t *deltas; ALPM_LOG_FUNC; @@ -708,6 +710,23 @@ pmpkg_t *_alpm_pkg_dup(pmpkg_t *pkg) newpkg->groups = alpm_list_strdup(alpm_pkg_get_groups(pkg)); newpkg->provides = alpm_list_strdup(alpm_pkg_get_provides(pkg)); newpkg->replaces = alpm_list_strdup(alpm_pkg_get_replaces(pkg)); + + /* copy all the delta objects */ + newpkg->deltas = NULL; + deltas = alpm_pkg_get_deltas(pkg); + while(deltas) { + pmdelta_t *d = malloc(sizeof(pmdelta_t)); + + if(d == NULL) { + _alpm_log(PM_LOG_ERROR, _("malloc failure: could not allocate %d bytes\n"), sizeof(pmdelta_t)); + RET_ERR(PM_ERR_MEMORY, NULL); + } + + memcpy(d, alpm_list_getdata(deltas), sizeof(pmdelta_t)); + newpkg->deltas = alpm_list_add(newpkg->deltas, d); + deltas = alpm_list_next(deltas); + } + /* internal */ if(newpkg->origin == PKG_FROM_FILE) { newpkg->origin_data.file = strdup(pkg->origin_data.file); -- 1.5.3.4

3 5

[pacman-dev] [GIT] The official pacman repository annotated tag, v3.0.1 now at v3.0.0-16-gef578e7
by Aaron Griffin 29 Oct '07

29 Oct '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 annotated tag, v3.0.1, to 23789e0c4ef99bf81235864b287c8ba7f3ec2090 (tag) replaces v3.0.0-15 tagged by Dan McGee <dan(a)archlinux.org> on 2007-10-28 23:48 -0400 - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- hooks/update --- Git Source Code Management System hooks/update refs/tags/v3.0.1 \ 0000000000000000000000000000000000000000 \ 23789e0c4ef99bf81235864b287c8ba7f3ec2090

3 2

[pacman-dev] [GIT] The official pacman repository annotated tag, v3.0.2 now at v3.0.1-17-g75b2001
by Dan McGee 29 Oct '07

29 Oct '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 annotated tag, v3.0.2, to 705aa06553481fb8ec452ca0a7c520fdbc8ef345 (tag) replaces v3.0.1-16 tagged by Dan McGee <dan(a)archlinux.org> on 2007-10-28 23:48 -0400 - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- hooks/update --- Git Source Code Management System hooks/update refs/tags/v3.0.2 \ 0000000000000000000000000000000000000000 \ 705aa06553481fb8ec452ca0a7c520fdbc8ef345

1 0

[pacman-dev] [GIT] The official pacman repository annotated tag, v3.0.3 now at v3.0.2-4-gafec5e4
by Dan McGee 29 Oct '07

29 Oct '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 annotated tag, v3.0.3, to 1d4251d2ad645bf319b27d8d16db70474fffff93 (tag) replaces v3.0.2-3 tagged by Dan McGee <dan(a)archlinux.org> on 2007-10-28 23:50 -0400 - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- hooks/update --- Git Source Code Management System hooks/update refs/tags/v3.0.3 \ 0000000000000000000000000000000000000000 \ 1d4251d2ad645bf319b27d8d16db70474fffff93

1 0

[pacman-dev] [GIT] The official pacman repository annotated tag, v3.0.4 now at v3.0.3-4-g8be3f1f
by Aaron Griffin 29 Oct '07

29 Oct '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 annotated tag, v3.0.4, to 7bc12516cd16636dbdeef222b453f72b1706b0e9 (tag) replaces v3.0.3-3 tagged by Dan McGee <dan(a)archlinux.org> on 2007-10-28 23:50 -0400 - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- hooks/update --- Git Source Code Management System hooks/update refs/tags/v3.0.4 \ 0000000000000000000000000000000000000000 \ 7bc12516cd16636dbdeef222b453f72b1706b0e9

1 0