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

[Dieter Plaetinck]

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 at 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 at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20081018/ddbd18a0/attachment.htm>