[pacman-dev] [PATCH v3 0/8] Patches for better optdep support
I'm flooding your inbox one last time (for the next two weeks), so you can all bitch about how crappy my patches are while I'm away ;-) This implements most features from https://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends (I've added some things regarding package removal there) I'v also added this here: https://wiki.archlinux.org/index.php/Pacman_Roadmap Github link: https://github.com/moben/pacman/tree/optdep What is there: - No regressions afaics - Only show uninstalled optdepends during install/upgrade - In package info, show [installed] after installed optdepends - In package info (local or -ii) show packages which optionally depend on the queried package - '-Qt' doesn't consider optdepends to be orphans, unless '--nooptdeps/-n' is given if it is given, display them like this: 'sqlite3 3.7.7.1-1 (optdepend for: dbmail, python)' - Recursive removal of unneeded optdeps What is still missing: - In package info display the description alongside the "reverse optdeps" [1] - Cascading to optdepends on package removal with an optional flag [2] - Warn when removing optdepends for installed packages [3] - Anything listed under "Other Ideas" - Tests (mainly needed for the package removal stuff I think) - Docs with less sucky english ;-) [1] Not sure if this would be to much and clutter the whole thing, especially for sync repos [2] Maybe '--optdeps/-o' (Related: make 'pacman -So foobar' install all optdepends) [3] like ':: foo: requires bar', but nonfatal Suggestions on how to implement [3]? I've looked at how it works for normal requires by getting ALPM_ERR_UNSATISFIED_DEPS from libalpm, but we don't want to raise an error here, so what to do? I'm still not sure about http://mailman.archlinux.org/pipermail/pacman-dev/2011-July/013886.html It sounds like a good idea, but would also mean changing (some|many|most|all) dep allocating functions from alpm_depend_t *func(foo) to int func(foo, alpm_depend_t *WriteThis) and make them not allocate the alpm_depend_t themselves. An alternative would be to create a new set of functions and make the current ones thin wrappers around those, so most code can stay as simple as it is now and use the allocated object. Comments? --- Benedikt Benedikt Morbach (8): Split optdep into alpm_depend_t and description Hook new optdepend structures up Only display uninstalled optdepends during install/upgrade Show optdep install status in package info optdepends are not orphans unless --nooptdepends is specified Make package info show optional requirements Make recursive removal consider optdepends Show list of optrequires with -Qtdn doc/pacman.8.txt | 6 ++ lib/libalpm/alpm.h | 14 +++++- lib/libalpm/be_local.c | 11 ++++- lib/libalpm/be_package.c | 5 +- lib/libalpm/be_sync.c | 7 ++- lib/libalpm/deps.c | 86 ++++++++++++++++++++++++++++++++- lib/libalpm/deps.h | 3 + lib/libalpm/package.c | 40 +++++++++++----- src/pacman/conf.h | 1 + src/pacman/package.c | 13 ++++- src/pacman/pacman.c | 3 + src/pacman/query.c | 27 +++++++++-- src/pacman/util.c | 120 +++++++++++++++++++++++++++++++++++++++------- src/pacman/util.h | 2 + src/util/pactree.c | 2 +- 15 files changed, 296 insertions(+), 44 deletions(-) -- 1.7.6
This is done as a preparation to better handle optdepends.
This commit should not change pacman's behaviour, as it simply adds new
functions and data structures and doesn't yet hook them up anywhere.
Signed-off-by: Benedikt Morbach
No new behaviour introduced, everything should work exactly as before.
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
Signed-off-by: Benedikt Morbach
On Mon, Aug 1, 2011 at 8:31 PM, Benedikt Morbach
- '-Qt' doesn't consider optdepends to be orphans, unless '--nooptdeps/-n' is given if it is given, display them like this: 'sqlite3 3.7.7.1-1 (optdepend for: dbmail, python)' <snip>
not sure if I can follow the logic here: --nooptdeps/-n is about not considering optdeps being no orphans - so, technically this is a double negation? As far as I can tell here that flag will add more to the output? mar77i
participants (2)
-
Benedikt Morbach
-
Martti Kühne