What about smartpm?

[seth vidal]

On Wed, 2005-11-30 at 11:48 +0800, Yuan Yijun wrote:
> 2005/11/30, Jeff Spaleta <jspaleta at gmail.com>:
> >
> > Are you here to argue semantics or are you here to have a constructive
> > conversation?
> > The issue is about "known" vulnerabilities and "expected" problems
> > based on how scriplets are designed to work.
> >
> > Vulnerabilities get fixed with upgrades as they are discovered and
> > developers respond. Its pretty clear to anyone willing to be rational,
> > that software updates are inspired to deal with "known"
> > vulnerabilities. Tools that takes the thought out of downgrading into
> > a known insecurity from a more security state does those users a
> > disservice.  This of course is not the strongest argument that can be
> > made against downgrading, since notification about security issues
> > could be incorporated either from the changelog difference or from
> > seperate notification text to inform the users of the risk.
> >
> > The stronger argument against this behavior is about how rpm packages
> > are actually designed and tested. How much testing does anyone do with
> > regard to downgrades? Is there any packager out there that creates
> > upgrades to fix issues regarding downgrading?
> > I'll go out on a limb and suggest that the number of maintainers who
> > do spend any time on making sure downgrades work smoothly is
> > vanishingly small. We know this situation gets absolutely no testing,
> > and gets absolutely no maintenance and as a result tools should not be
> > automating the process when the results are ill-defined.
> >
> > -jef
> >
> 
> When you say "upgrade", you mean "always upgrade to the newest
> version", even if there is one that is not the newest but newer than
> none and can satisfy the dependencies of another software? I don't
> want to wait for both  becoming newest, I want to use it now. If using
> yum, I must disable the repo which contains the newest dependencies
> AFAIK. This happens with gstreamer repo, but I cannot remember it
> clearly.

but think about that.

So let's say in all the repos you have:

foo-1.0
foo-1.5
foo-2.0

you want to install bar 1.5 which requires foo-1.5

so let's say yum did that and installed bar 1.5 and foo 1.5.
What's going to happen the next time you run yum update?

It's going to put update you do foo-2.0

so why not cut out the intermediate step.

-sv