January 2009 - Pacman-dev - lists.archlinux.org

[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

[pacman-dev] [PATCH 5/5] Removed some unwanted error logging, as requested by the pacman-dev list
by Bryan Ischo 14 Jan '09

14 Jan '09

Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/deps.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-)

1 0

[pacman-dev] [PATCH 4/5] Removed prompt that asked the user if they wanted to install an IgnorePkg/IgnoreGroup dependency
by Bryan Ischo 14 Jan '09

14 Jan '09

This is because the new prompt asking the user if they want to remove the offending packages from the transaction replaces this functionality. 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 3/5] Added a new transaction callaback question that enables the new ignore unresolved package feature if the user wants to
by Bryan Ischo 14 Jan '09

14 Jan '09

All tests pass. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/alpm.h | 2 +- lib/libalpm/deps.c | 4 +--- 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 +++++++++++++++++++++++++ 7 files changed, 31 insertions(+), 8 deletions(-)

1 0

[pacman-dev] [PATCH 2/5] Added logic to support removing ignored packages and their dependents from sync transactions.
by Bryan Ischo 14 Jan '09

14 Jan '09

This code should have no effect on the pacman runtime until a future commit which will enable the logic paths that actually remove ignored packages. In the meantime, all pactest tests pass without any modification. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/deps.c | 247 +++++++++++++++++++++++++++++++++++++++++++++++----- lib/libalpm/deps.h | 4 +- lib/libalpm/sync.c | 11 ++- 3 files changed, 231 insertions(+), 31 deletions(-)

1 0

[pacman-dev] Switch to libfetch-only support (was: The official pacman repository branch, master, updated. v3.2.2-58-ge3a0696)
by Dan McGee 14 Jan '09

14 Jan '09

On Tue, Jan 13, 2009 at 7:52 PM, Dan McGee <dan(a)archlinux.org> wrote: > commit 8017b0bb8ec5364f8a3999caffc6b3c3ea991810 > Author: Xavier Chantry <shiningxc(a)gmail.com> > Date: Sat Nov 15 10:10:56 2008 +0100 > > Remove libdownload support and fix libfetch one. > > Aaron said to consider libdownload a dead project so libdownload support was > removed to more easily fix libfetch one (otherwise many ifdef needed). > > There was no direct replacement for ferror to detect an error while > downloading. So instead, I added a check at the end to see if the file was > fully downloaded, which is just a small chunk of code taken from here: > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/net/libfetch/files/fetch.c?only_… > > Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> > Signed-off-by: Dan McGee <dan(a)archlinux.org> Note that this commit means libdownload is no longer supported. Arch has a libfetch package in testing that works perfectly with pacman built from GIT, so please install that if you want to continue to be able to compile. :) -Dan

2 1