One option smart needs to conquer the world

[Axel Thimm]

On Thu, Feb 23, 2006 at 11:47:44AM -0500, seth vidal wrote:
> On Thu, 2006-02-23 at 17:39 +0100, 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.
> 
> So how is your concern about upgrading into a problem or not being able
> to upgrade b/c of a broken repository any less valid than my concern
> about downgrading into a security problem?

It's not *less* valid :)

> I don't disagree with you that someone could be stuck unable to upgrade
> b/c of a dependency issue - but I see that as a problem the repository
> needs to solve - not a problem that the depsolver needs to do.

You assume a perfect world, and ther eis no perfect reposititory and
there will never be one. You know that, you've seen the breakage of
Fedora *update* repos. And if you lay so much weigh on security
updates then a depsolver should do its best to extract at least the
non messed up packages from the updates, right?

> Moreover a good number of updates are released for security reasons and
> downgrading is not considered safe by security officers all over the
> place. We KNOW that downgrading has that potential. At least by
> upgrading you're upgrading into what is intended to be an improvement.

But you are aware that the downgrade does happen on rainy sundays (I
repeat myself, I know). It happens in order to allow other upgrades to
happen. So at least you get some updates and thus potential better
security protection than bailing out and leaving the user on its own
waiting for something to happen on the server.

> > 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
> > way, non-smart depsolvers will not be able to render your system
> > secure. and it's not an academic example, it happened very often
> > during early FC4 release, where there was a flurry of updates in the
> > first weeks, and it will happen again with FC5.
> 
> And the issue of downgrading into oblivion could occur as well. It's not
> an academic example, either.

OK, where is the real-life example?

> I really would like to know how your concerns are any less valid
> than mine.

They aren't less valid :)

> > I wouldn't compare them at all. For any security breach example
> > non-smart followers come up with you can provide a
> > counter-example.
> > 
> > > Is there any middle ground short of adding the option in smart?
> > 
> > Ignore the FUD and enjoy a great tool?
> 
> How is your example less FUD than mine?

So, you're admiting to be FUDding, heh? ;) I'm not scaring away people
from yum, the arguments that are layed down here is how yum
users/developers try to FUD out smart, apt and the like (yep, I've
been around to remember the yum vs apt fud war).

> It seems like we have two solutions to a similar problem and two
> programs have taken different paths.
> 
> I really don't  see the conflict here at all.

So, you don't see any issues in smart's handling and would welcome it
aboard Fedora Core (with a test time in Extras)? May I quote that? ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20060223/85fe6f36/attachment-0003.pgp>