[pacman-dev] "explicit dependencies", a compromise between explicit and deps
Hi, pacman has an option --asdeps so the user can install packages as if it were deps. In fact, such packages will be treated exactly the same as normal dependencies: - if no explicit package depends on them, they will be considered orphans and are subject to be cleaned up, along with 'real' orphans. This can be a good thing when the user installs the packages --asdeps assuming a package will state them as dep later on. if doesn't happen it can really be considered an orphan and can be deleted. This can be a bad thing when the user installs the packages --asdeps because no package states the dependencies on them, but they are needed/wanted for some reason. (Often this means the "dependent" package misses a dependency and this package should be fixed, but not always) - in a backup/restore or clone system scenario the usual approach is to do 'pacman -Qe' to get a package list. When restoring/installing the list on another box this means we install only the explicit packages and their dependencies. Some packages we installed ourself --asdeps will get lost. This is not always good. A current workaround would be to install these packages explicitly, but doesn't always feel right either because we don't want the package explictly, although we do want them because they provide features to a package even though it's not really needed. In fact, this is very similar to the 'recommends' directive in debian package. Many arch packages literally say 'install x to have feature foo, install y to have feature bar' (these are the 'recommended' packages). If the user then installs x or y they are not really explicit packages (because we only want them because we use another package that recommends them), but they are not dependencies either (otherwise they will get lost) What I propose is an intermediate state between 'explicit' and 'dependency', called 'explicit dependency'. This would be the new default way when the user wants to install something as a dep (usually because a package recommended it), whereas the 'old' '--asdeps' installs a package as a 'real' dependency (eg: do this only when you're sure you'll install a package that depends on them, otherwise the package will be an orphan and get cleaned up someday or not be restored when restoring/cloning a system) What are your ideas? Thanks, Dieter
On Sun, Oct 12, 2008 at 01:25:38PM +0200, Dieter Plaetinck wrote:
- in a backup/restore or clone system scenario the usual approach is to do 'pacman -Qe' to get a package list. When restoring/installing the list on another box this means we install only the explicit packages and their dependencies. Some packages we installed ourself --asdeps will get lost. This is not always good. A current workaround would be to install these packages explicitly, but doesn't always feel right either because we don't want the package explictly, although we do want them because they provide features to a package even though it's not really needed. In fact, this is very similar to the 'recommends' directive in debian package. Many arch packages literally say 'install x to have feature foo, install y to have feature bar' (these are the 'recommended' packages). If the user then installs x or y they are not really explicit packages (because we only want them because we use another package that recommends them), but they are not dependencies either (otherwise they will get lost)
What you should do is install those packages explicitly and they should be registered as explicit packages but also show up as dependencies.
Dieter Plaetinck wrote:
Hi, pacman has an option --asdeps so the user can install packages as if it were deps. In fact, such packages will be treated exactly the same as normal dependencies: <blah> What are your ideas? Thanks, Dieter
That explanation made my head hurt.... So to put it succinctly, you want a category for packages that are sort of dependencies, but not real dependencies, but are not explicitly installed either. So something you install because (e.g.) it is an optdepend. I can see your point, but it does seem that adding another category of package is a bit extreme. I do run into this problems as I have to install optdepends as explicit as I use --asdep as a mechanism to keep track of packages I am testing so I can just remove orphans to clean my system. Maybe an option to set what packages you install something as a dependency of is a compromise (still not sure how that would work....). Allan
On Sun, Oct 12, 2008 at 8:24 AM, Allan McRae <allan@archlinux.org> wrote:
Dieter Plaetinck wrote:
Hi, pacman has an option --asdeps so the user can install packages as if it were deps. In fact, such packages will be treated exactly the same as normal dependencies: <blah> What are your ideas? Thanks, Dieter
That explanation made my head hurt.... So to put it succinctly, you want a category for packages that are sort of dependencies, but not real dependencies, but are not explicitly installed either. So something you install because (e.g.) it is an optdepend.
I can see your point, but it does seem that adding another category of package is a bit extreme. I do run into this problems as I have to install optdepends as explicit as I use --asdep as a mechanism to keep track of packages I am testing so I can just remove orphans to clean my system. Maybe an option to set what packages you install something as a dependency of is a compromise (still not sure how that would work....).
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so: $ pacman -S foobar Optional dependencies for foobar: baz $ pacman -S --asdep baz What we have here is 'baz' indicated as an orphan, but what we *want* is baz indicated as "Required By" foobar, correct? If so, then it is just a matter of adding more logic to the optdepends property. That is: a) Split entries on ':', and resolve package names (warn if not found?) b) Use optdepend packages when resolving things like orphans and requiredby lists. If I understand your qualm right, this would be a better way to handle this.
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so: $ pacman -S foobar Optional dependencies for foobar: baz $ pacman -S --asdep baz
What we have here is 'baz' indicated as an orphan, but what we *want* is baz indicated as "Required By" foobar, correct?
If so, then it is just a matter of adding more logic to the optdepends property. That is: a) Split entries on ':', and resolve package names (warn if not found?) b) Use optdepend packages when resolving things like orphans and requiredby lists.
If I understand your qualm right, this would be a better way to handle this.
Hmm. This is a valid point. OK, I suppose that alpm can parse and handle %OPTDEPENDS% field. What should we do in the following situation?: User installs foo, which pulls bar as dep, as well. Later he installs baz which has bar as optdepend. At this point (without user interaction) we don't know whether user need bar as optdepend of foo, so it is not clear what to do after "pacman -Rs foo". Without extra bookkeeping, we cannot suspect user needs. So I suggest some new switch ~--optdepend, which simply means that pacman treats optdepends like real depends. Maybe this can be useful with -S, -Rs, or -Qd. However, this method is not useful, if you have custom needs. Then some extra bookkeeping is needed (maybe turn some optdepend to real depend in local db during install?). Bye ------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so: $ pacman -S foobar Optional dependencies for foobar: baz $ pacman -S --asdep baz
What we have here is 'baz' indicated as an orphan, but what we *want* is baz indicated as "Required By" foobar, correct?
If so, then it is just a matter of adding more logic to the optdepends property. That is: a) Split entries on ':', and resolve package names (warn if not found?) b) Use optdepend packages when resolving things like orphans and requiredby lists.
If I understand your qualm right, this would be a better way to handle this.
Hmm. This is a valid point.
OK, I suppose that alpm can parse and handle %OPTDEPENDS% field.
What should we do in the following situation?: User installs foo, which pulls bar as dep, as well. Later he installs baz which has bar as optdepend. At this point (without user interaction) we don't know whether user need bar as optdepend of foo, so it is not clear what to do after "pacman -Rs foo". Without extra bookkeeping, we cannot suspect user needs.
So I suggest some new switch ~--optdepend, which simply means that pacman treats optdepends like real depends. Maybe this can be useful with -S, -Rs, or -Qd.
However, this method is not useful, if you have custom needs. Then some extra bookkeeping is needed (maybe turn some optdepend to real depend in local db during install?).
It'd make more sense to me to NOT descend into optdepends at all when removing. It would be an extra step for the end user (remove packages, check and remove new orphans), but it would simplify the pacman side. To put it more concisely: optdepends should NOT be treated like depends when installing or removing.
On Tue, Oct 14, 2008 at 11:26 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so:
Can I take a step back here and say this: we're getting greedy. When we introduced optdepends, we were (I was?) just trying to remove need for install files with metadata only. Moving it into the package made sense, but I never anticipated it flowering into all this complexity that has been brought up in this thread. What happened to tweaking things on your own if necessary? I'm just not convinced we want to go down the road to complexity and extra features here, especially if the trend continues. "Well what if I installed a package as an optdepend for this one, but don't want it to be an optdepend for this other one?" The list of scenarios seems endless and I fear fixing one will open the floodgates for 3 more use cases. -Dan
On Tue, Oct 14, 2008 at 7:01 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Can I take a step back here and say this: we're getting greedy.
When we introduced optdepends, we were (I was?) just trying to remove need for install files with metadata only. Moving it into the package made sense, but I never anticipated it flowering into all this complexity that has been brought up in this thread. What happened to tweaking things on your own if necessary?
I'm just not convinced we want to go down the road to complexity and extra features here, especially if the trend continues. "Well what if I installed a package as an optdepend for this one, but don't want it to be an optdepend for this other one?" The list of scenarios seems endless and I fear fixing one will open the floodgates for 3 more use cases.
I did not participate to this thread before because I share the same feeling.
Okay, by now I've/we've realized that the original "explicit dependencies" terminology is just a way of categorizing installed optdeps. (I can't think of another use case then that) When I wrote the first mail I didn't realize this clearly enough yet. So my explanations and terminology are a bit blurry. Sorry for making your head hurt, Allan.
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so: $ pacman -S foobar Optional dependencies for foobar: baz $ pacman -S --asdep baz What we have here is 'baz' indicated as an orphan, but what we *want* is baz indicated as "Required By" foobar, correct?
Yes, sort of.. It's not a hard dependency though.
b) Use optdepend packages when resolving things like orphans and requiredby lists.
I like this.
What should we do in the following situation?: User installs foo, which pulls bar as dep, as well. Later he installs baz which has bar as optdepend. At this point (without user interaction) we don't know whether user need bar as optdepend of foo, so it is not clear what to do after "pacman -Rs foo". Without extra bookkeeping, we cannot suspect user needs.
A very valid point, but what's wrong with user interaction? Isn't just asking the user "Do you also want to remove bar, it's not strictly needed anymore but it's an optdepend for baz?" a simple and solid way to resolve this? I wouldn't use commandline flags (uninteractive) for this because that would mean the user knows exactly on the beforehand how all his/her packages are related to each other. Warning the user, and explaining him, and letting him sort it out himself seems like the best approach to me. Dan/Xavier, I see your point. Indeed, you can always have more use cases who would 'need' this or that feature, which would make alpm unnecessarily complicated in comparison with the little added benefit for a select few users *if* you want all those features to be implemented in such a way that they work automatically without user interaction. But that doesn't need to be the case! Maybe we should just strive for a method to create a list of those packages that we (might) have installed because they were interesting optdepends. That way, the list doesn't need to be 100% accurate. (because if we want to achieve that, that would be why we would make alpm more complex, and that's where your examples come in). The list may contain too many packages, as long as no packages are forgotten. Filtering out the list is something that can still be done by the user. What if I say: never mind about the extra category ('explicit dependencies'), let's enhance pacman so that when it compiles a list of orphans, it can mark the ones that are listed by some other package as optdepend (and show those packages)? That way, we don't make anything unnecessarily complex, but we still have a solutions for the problems described in the various emails. They require some manual interaction, but with the right scripts and by showing the appropriate information where needed, this can become a very easy task, I think. Dieter. Xavier wrote:
On Tue, Oct 14, 2008 at 7:01 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Can I take a step back here and say this: we're getting greedy.
When we introduced optdepends, we were (I was?) just trying to remove need for install files with metadata only. Moving it into the package made sense, but I never anticipated it flowering into all this complexity that has been brought up in this thread. What happened to tweaking things on your own if necessary?
I'm just not convinced we want to go down the road to complexity and extra features here, especially if the trend continues. "Well what if I installed a package as an optdepend for this one, but don't want it to be an optdepend for this other one?" The list of scenarios seems endless and I fear fixing one will open the floodgates for 3 more use cases.
I did not participate to this thread before because I share the same feeling. _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
On Sat, Oct 18, 2008 at 9:14 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
Maybe we should just strive for a method to create a list of those packages that we (might) have installed because they were interesting optdepends. That way, the list doesn't need to be 100% accurate. (because if we want to achieve that, that would be why we would make alpm more complex, and that's where your examples come in). The list may contain too many packages, as long as no packages are forgotten. Filtering out the list is something that can still be done by the user. What if I say: never mind about the extra category ('explicit dependencies'), let's enhance pacman so that when it compiles a list of orphans, it can mark the ones that are listed by some other package as optdepend (and show those packages)? That way, we don't make anything unnecessarily complex, but we still have a solutions for the problems described in the various emails. They require some manual interaction, but with the right scripts and by showing the appropriate information where needed, this can become a very easy task, I think.
Perhaps another -Q flag that would take optdepends into account?
Hi! I think you misinterpret something.
This can be a bad thing when the user installs the packages --asdeps because no package states the dependencies on them, but they are needed/wanted for some reason. (Often this means the "dependent" package misses a dependency and this package should be fixed, but not always)
In this case user should install the package explicitly.
What I propose is an intermediate state between 'explicit' and 'dependency', called 'explicit dependency'. This would be the new default way when the user wants to install something as a dep (usually because a package recommended it), whereas the 'old' '--asdeps' installs a package as a 'real' dependency (eg: do this only when you're sure you'll install a package that depends on them, otherwise the package will be an orphan and get cleaned up someday or not be restored when restoring/cloning a system)
explicit dependency =3D=3D explicit. Maybe 'implicit' terminology would be better instead of 'dependency'. For details, read my (ngaba) comment here: =20 http://bbs.archlinux.org/viewtopic.php?id=3D55526 Bye P.S.: Sorry about my previous direct reply (I hate horde). ------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
participants (7)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Dieter Plaetinck
-
Loui
-
Nagy Gabor
-
Xavier