One option smart needs to conquer the world

[Axel Thimm]

On Thu, Feb 23, 2006 at 12:13:35PM -0500, seth vidal wrote:
> On Thu, 2006-02-23 at 18:00 +0100, Axel Thimm wrote:
> > 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?
> 
> Not exactly. I think that erroring well and warning the user
> appropriately is the most correct action. It is the sysadmin's job to
> make sure the repositories are correct.

So how does a sysadmin fix the vendors' repo? Phone call?

> > > 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?
> 
> When a downgrade could walk you into a security issue? Look at any of
> the security updates and think about what happens if you downgrade and
> don't know any better.

An acadademic example is a theoretical one, just like the one you give
again. A non-academic example is a more-to-the earth one, e.g. one
that has already occured. Like the blocking of upgrades by yum, just
to give two examples I found gooling for a minute (and I know there
are more) about when the vendors' update channel messed up so yum
refused to work at all (but according to your opinion it's the most
correct action):

https://www.redhat.com/archives/fedora-list/2005-August/msg03536.html
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145415

So, please give an approriate example on how smart has messed/blocked
security issues, or would have done so. At the time being there are
multiple real-life examples on how yum blocks security updates (from
the vendor!!!) vs FUD about potential security issues when allowing to
downgrade packages.

> The only thing I've read in this thread from you is messages that allege
> a lot of behavior from yum developers that I've just not seen.

Well, I wasn't expecting you to think otherwise, I guess.

> > > 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? ;)
> 
> I don't think two depsolvers in core is a good idea and I know that
> fedora core developers agree with me about that. The only thing
> limiting Smart from being in extras is it being hung up on the
> approval step, iirc.
> 
> I don't understand why you feel the need to talk about
> 'quoting'. From what I've seen so far you seem rather driven to get
> something out of me you'll not find.

I'm not expecting anything. I'm just having fun talking with you.
-- 
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/90c09c8c/attachment-0003.pgp>