[pacman-dev] "explicit dependencies", a compromise between explicit and deps

newer
[pacman-dev] [PATCH] repo-add: Use...

Dieter Plaetinck

12 Oct 2008 12 Oct '08

11:25 a.m.

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

Show replies by date

Loui

12 Oct 12 Oct

1:16 p.m.

New subject: [pacman-dev] "explicit dependencies", a compromise between explicit and deps

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.

Allan McRae

1:24 p.m.

New subject: [pacman-dev] "explicit dependencies", a compromise between explicit and deps

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

Aaron Griffin

13 Oct 13 Oct

8:48 p.m.

On Sun, Oct 12, 2008 at 8:24 AM, Allan McRae 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.

Nagy Gabor

14 Oct 14 Oct

10:27 a.m.

New subject: [pacman-dev] "explicit dependencies", a compromise between explicit and deps

...

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/

Aaron Griffin

4:26 p.m.

On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor 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.

Dan McGee

5:01 p.m.

On Tue, Oct 14, 2008 at 11:26 AM, Aaron Griffin wrote:

...

On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor 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

Xavier

5:32 p.m.

On Tue, Oct 14, 2008 at 7:01 PM, Dan McGee 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.

Dieter Plaetinck

18 Oct 18 Oct

2:14 p.m.

New subject: [pacman-dev] "explicit dependencies", a compromise between explicit and deps

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 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

Aaron Griffin

10:18 p.m.

On Sat, Oct 18, 2008 at 9:14 AM, Dieter Plaetinck 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?

Nagy Gabor

12 Oct 12 Oct

1:44 p.m.

New subject: [pacman-dev] "explicit dependencies", a compromise between explicit and deps

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/

5676

Age (days ago)

5682

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Aaron Griffin
Allan McRae
Dan McGee
Dieter Plaetinck
Loui
Nagy Gabor
Xavier