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