One option smart needs to conquer the world

[Mauricio Teixeira]

Axel Thimm wrote:

> It could just be the opposite, too. The downgrading of package foo in
> smart happens not because it's a rainy sunday, but because you asked
> smart to perform an operation like perhaps upgrading another package,
> bar, that *does* has a security issue.

I'm just reading your comments because I think I have nothing else
interesting to add to that discussion better than you all have been
saying. Very productive talk indeed.

I decided to break up my (less important) silence just to say that (if
that matters anyone) I would use the above quoted argument as one of the
reasons why Smart works out better than others. I completely agree with
Gustavo when he says that Smart should do what the user *asks to* even
if it needs to downgrade something, and Axel's comment is the perfect
complement for that argument.

> Another depsolver would say: No, I won't upgrade bar to version 2
> because foo requires bar = 1. So as long as the repo is broken that

It's very possible to have that erroneous behaviour when you have many
different 3rd-party repositories that handles the same package (with
different versions). Some day someone will screw up the "Requires" or
"Provides" tags and you'll get a broken dependency solving. In most
cases enforcing priorities on channels and/or packages would solve that
problem.

-- 
% Mauricio Teixeira (netmask)
% mteixeira{a}webset{d}net <> Maceio/AL/BR
% TI+Telecom Analyst <> Linux Specialist
% http://mteixeira.webset.net <> http://pmping.sf.net
% [D0CE 6BD4 526B B7D1 6F4E  85FA A7A0 1A6F B23A A9EE]