- Pacman-dev - lists.archlinux.org

[pacman-dev] My new patches
by Bryan Ischo 17 Jan '09

17 Jan '09

The first three patches I just sent to the list encompass the new implementation of the IgnorePkg/IgnoreGroup behavior. These changes are much smaller (although the addition of better documentation blocks makes them look bigger than they are in terms of code size) than my previous changes, but they accomplish the same thing (albeit slightly less efficiently in some cases). The last patch is the change to the pactest/README which incorporates feedback from the list. I tried to make these emails include the patches inline but I do not know if I was successful. I used the command: git format-patch --signoff --stdout --inline HEAD^^^^ | git imap-send To generate the emails and get them to my IMAP server, from where I sent them. In future I might use git send-email instead, I found it convenient to use git imap-send but if it doesn't produce properly inlined messages, I can switch to git send-email. Thanks, Bryan

2 1

[pacman-dev] [PATCH 4/4] Fixed some inconsistencies and errors in the pactest documentation.
by Bryan Ischo 17 Jan '09

17 Jan '09

Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- pactest/README | 25 ++++++++++++++++--------- 1 files changed, 16 insertions(+), 9 deletions(-)

1 0

[pacman-dev] [PATCH 3/4] Don't prompt the user for unignore of IgnorePkg/IgnoreGroup packages except for packages explicitly listed for sync by the user.
by Bryan Ischo 17 Jan '09

17 Jan '09

This eliminates many unnecessary prompts when IgnorePkg/IgnoreGroup is used. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/deps.c | 20 +++++++++++------- lib/libalpm/deps.h | 2 +- lib/libalpm/sync.c | 4 +- pactest/tests/ignore001.py | 17 ++++++++++++++++ pactest/tests/ignore002.py | 35 +++++++++++++++++++++++++++++++++ pactest/tests/ignore003.py | 35 +++++++++++++++++++++++++++++++++ pactest/tests/ignore004.py | 46 ++++++++++++++++++++++++++++++++++++++++++++ pactest/tests/ignore005.py | 46 ++++++++++++++++++++++++++++++++++++++++++++ src/pacman/callback.c | 11 +-------- 9 files changed, 196 insertions(+), 20 deletions(-) create mode 100644 pactest/tests/ignore001.py create mode 100644 pactest/tests/ignore002.py create mode 100644 pactest/tests/ignore003.py create mode 100644 pactest/tests/ignore004.py create mode 100644 pactest/tests/ignore005.py

1 0

[pacman-dev] [PATCH 2/4] Enabled a new prompt to ask the user if they'd like to remove unresolvable packages from the transaction rather than failing it.
by Bryan Ischo 17 Jan '09

17 Jan '09

Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/alpm.h | 3 ++- lib/libalpm/deps.c | 2 +- lib/libalpm/sync.c | 24 ++++++++++++++++++------ pactest/tests/provision020.py | 2 +- pactest/tests/provision022.py | 2 +- pactest/tests/sync1008.py | 2 +- pactest/tests/sync300.py | 2 +- src/pacman/callback.c | 25 +++++++++++++++++++++++++ 8 files changed, 50 insertions(+), 12 deletions(-)

1 0

[pacman-dev] [PATCH 1/4] Internal code reorganization in preparation for changes to package resolution.
by Bryan Ischo 17 Jan '09

17 Jan '09

This change reorganizes the internal code so that packages are resolved one at a time instead of all at once from a list. This will allow a future checkin to prompt the user to see if they'd rather remove unresolvable packages from the tranasaction and continue, or fail the transaction. This change does not affect the actual behavior of libalpm and all tests pass without changes. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/deps.c | 64 +++++++++++++++++++++++++++++++++++++++++++--------- lib/libalpm/deps.h | 5 ++- lib/libalpm/sync.c | 52 +++++++++++++++++++++++++++++++++--------- 3 files changed, 97 insertions(+), 24 deletions(-)

1 0

[pacman-dev] Should sync_newversion search for replacements?
by Nagy Gabor 16 Jan '09

16 Jan '09

This discussion is motivated by FS#11737. A replacement is nothing more than a simple upgrade with package name change. (This is plausible, but we don't really follow this principle atm.) So if we moved our find_replacments code to sync_newversion our code would be more readable [1]. Benefits: -Qu would also show the should-be-replaced outdated packages. -During this refactoring we could easily implement FS#11737. sync_newversion() on foo would do the following: for each database we try to find a "matching" package (pkgname == foo or bar replaces foo), and we decide if this is an upgrade or not (if not, return with NULL; replacement is always an upgrade). This is exactly what we want. (This demonstrates [1] imho.) Problems: -checking replaces is slower, because we must read some desc files, and sync_newversion() is called in every -S operation (pacman new version check). If the user's first repo is not core, pacman won't find pacman literal in this repo and will search for replacements in this repo before moving to the next repo. This is not a problem with -Su, because now we always search for replacements first. However, this can be easily fixed by adding a check_replacements boolean param to sync_newversion. (However, considering replacements for SyncFirst packages sounds better theoretically: User can specify any package there, not only pacman/glibc whose name probably won't change in the future.) -user interaction around replacements. Solution1: Basically I don't like user interaction. Why this PM_TRANS_CONV_REPLACE_PKG is needed at all? My distro says, that foo is _the_ new version of bar, if I don't want to upgrade bar, I put bar or foo to ignorepkg. (Of course we should at least print warning: "foo replaces bar".) Solution2 (uglier): sync_sysupgrade can compare new and old package name, if they differ this is a replacement and can get user confirmation. (Or other direct communication between the 2 functions.) -however, there is a bigger problem: Multiple package can replace one package (package split). So if we want to be precise, we should change the return value of sync_newversion to a package set (alpm_list), not a simple package, which is totally in needless in most cases. This annoying fact seems to be a show-stopper... (I don't like ugly code ;-) So the question is: Should we follow the following rule?: "At most one package can replace foo per repo." This is restriction on distro side, and usually I don't like restrictions. However, I don't know that we have ever replaced one package by a package set (in Archlinux). And in fact, replacing by a package set can be confusing to the user: "Do you want to replace foo with repo1/bar?" Y "Do you want to replace foo with repo2/baz?" What? I have already replaced foo. I can choose or it is recommended to use both replacement? If repo1 != repo2, probably I don't want to install both replacements (this situation cannot happen in our new approach). In most cases we can live with one replacement ("core" component or using dependencies) If we don't want to follow this rule: Should I drop this whole idea or use alpm_list_t or do you have any better idea? Bye

2 1

[pacman-dev] Another idea
by Bryan Ischo 16 Jan '09

16 Jan '09

Hey all. I've been thinking about my patches and the concerns that list members have had about them and I've come up with a different way of accomplishing the same thing that may be more palatable: - Modify the signature of deps.c:_alpm_resolvedeps so that it takes, instead of a list of packages to resolve, a single package. It would return 0 if the resolve succeeded, 1 if the resolve failed, and would additionally return a list of dependencies that this package needs for this sync. In the parlance of _alpm_resolvedeps, it would return the 'pulled' list. _alpm_resolvedeps would, just as it does now, fail immediately when it encountered an unresolvable dependency, and would not require the graph structure to keep track of dependents. It would be a much simpler change to _alpm_resolvedeps. - Modify sync.c:_alpm_sync_prepare so that it calls _alpm_resolvdeps once per package in the transaction, rather than calling _alpm_resolvedeps once with a list of the packages in the transaction as it does now. As _alpm_resolvedeps is called for each package in the transaction, three lists will be built up in _alpm_sync_prepare: 1. The list of transaction packages (i.e. the "top-level" packages) that were successfully resolved. 2. The list of transaction packages (i.e. the "top-level" packages) that were NOT successfully resolved. 3. The list of "pulled" packages that came from _alpm_resolvedeps for each transaction package that was successfully resolved. After all of the resolution has been done, if the list in (2) is not empty, then these packages are used in the new prompt that asks the user "do you want to ignore these packages for this transaction", and if they say "no", then _alpm_sync_prepare will return a failure status code. If they say "yes", then list (2) will be freed and list (1) and (3) will be used to finish _alpm_sync_prepare as normal (after removing duplicates from (3) as necessary). The advantage of this approach is that it doesn't require any new data structures or helper functions, and changes _alpm_resolvedeps very little. The disadvantage of this approach is that it is less efficient at runtime. Each top-level package will be resolved individually, which means that some work will be duplicated (i.e. if top-level A and B depend on C, and C depends on D and E, then in this new scheme, the C-D-E dependencies will be calculated once for A and once for B, whereas before, it was only calculated once for A, and then the results re-used for B). I would only expect this to have a significant perfomance penalty in large transactions (say a pacman -Su where hundreds of packages were being updated), and I'm not sure exactly how "large" the transaction would have to be before the penalty became unreasonable. I *think* these are the only two approaches: 1. Use a data structure to track dependents, thus gaining runtime efficiency during the resolve of a list of packages, at the expense of extra complexity in the implementation 2. Use no new data structures, instead iterating over each package in the transaction individually, thus gaining simplicity of implementation, at the expense of runtime efficiency I have already implemented (1). If the concern about the code complexity outweighs the concern about performance, then I can implement (2) instead. Please let me know how to proceed. Thanks. Bryan T

4 6

[pacman-dev] [PATCH] Make the repo-add quiet flag less quiet
by aaronmgriffin＠gmail.com 15 Jan '09

15 Jan '09

From: Aaron Griffin <aaronmgriffin(a)gmail.com> Considering one can easily run: repo-add .... >/dev/null to get only warnings and errors, the -q flag is mostly useless. Make the -q flag silence only level 2 messages Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> --- scripts/repo-add.sh.in | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 4f9639c..c89e2a5 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -34,7 +34,6 @@ REPO_DB_FILE="" umask 0022 msg() { - [ $QUIET -ne 0 ] && return local mesg=$1; shift printf "==> ${mesg}\n" "$@" >&1 } @@ -68,8 +67,8 @@ repo-remove will update a package database by removing the package name\n\ specified on the command line from the given repo database. Multiple\n\ packages to remove can be specified on the command line.\n\n")" printf "$(gettext "\ -The -q/--quiet flag to either program will force silent running except\n\ -in the case of warnings or errors.\n\n")" +Use the -q/--quiet flag to minimize output to basic messages, warnings,\n\ +and errors\n\n")" echo "$(gettext "Example: repo-add /path/to/repo.db.tar.gz pacman-3.0.0.pkg.tar.gz")" echo "$(gettext "Example: repo-remove /path/to/repo.db.tar.gz kernel26")" } -- 1.6.0.5

3 3

[pacman-dev] [PATCH 1/5] Fixed some innacuracies in the pactest README
by Bryan Ischo 14 Jan '09

14 Jan '09

Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- pactest/README | 14 +++++--------- 1 files changed, 5 insertions(+), 9 deletions(-)

4 11

[pacman-dev] New Patches
by Bryan Ischo 14 Jan '09

14 Jan '09

Hey all. I've broken my change into 5 patches, which have already been sent to the list. The big one is patch #2, which adds the new ignore logic to deps.c. Although the number of lines edited is large, it's just the addition of a new data structure, some helper methods, and a rework of _alpm_resolvedeps(). There is no way to reduce the size of this patch. I hope that these patches are satisfactory. If you'd just give them a try they should merge nicely into your tree. Create a branch and merge them in and test them out. That's what git is good at right?!? Please note that these patches replace all previous patches I've sent to this list. Thanks, Bryan

2 3