On Sat, 2005-11-26 at 08:55 -0800, MJang wrote: > > A couple of months ago, I was under the impression that all the distros > were moving in that direction, as Smartpm can handle upgrades to both > RPMs and DEBs and can work from all kinds of repositories (apt, yum, > urpmi, slack, etc.). Is Smartpm still under consideration for FC5? As far as I know, no. Duplicate functionality. Fedora doesn't use apt, no need to worry about that from a Fedora standpoint. Fedora uses yum, yum cli updates, pup graphically updates.

Partially true - but yum is smart, and smart is smarter. For example, just this morning yum quit updating. I don't recall the details, but I had installed videolan-client from dries yum repos, and an update of one of it's depends (from a different repo) broke it. yum was stymied. smart just offered to downgrade the depend, and happily fixed it.

I don't think so. It's like this: I want to install appA. It has depB. repoA and repoB both have depB. repoA has appA. Installing (via yum, smart, or whatever) picks up appA from repoA, and depB from repoB. Now, repoB updates depB. No reason it shouldn't. Now, IIUC, yum gives up on this situation. It wants to update depB, but appA needs the old version. IIUC, not only does yum not update depB, but it _stops updating anything completely_. Your nightly yum upgrade stops until you notice the problem and manually repair it. (Correct me if I'm wrong here).

> It's because this is a safer behaviour than guessing around various > errors. You think it's wonderful, but it's far more error-prone than not > doing anything "automagically" until the problem is actually fixed. > Working around brokenness is a very slippery path to far graver and more > obscure brokenness down the line. > Perhaps it was a bad example (I don't think smart will break deps to perform an upgrade, but I could be wrong). Some interesting cases (where indeed both yum and apt fail): http://zorked.net/smart/doc/README.html#study-cases

> Yeah, and this is still unsafe, because downgrading is inherently, > implicitly unsafe. > > 1. You can downgrade into a vulnerability > 2. Downgrading often breaks, since newer version can do things in %post > that make downgrading to a workable state impossible > Can I not reverse this argument to state: Yeah, and this is still unsafe, because upgrading is inherently, implicitly unsafe. 1. you can upgrade into a vulnerability 2. upgrading often breaks, since newer versions can do things in %pre that make upgrading to a workable state impossible. And have it be equally valid? ;)

Yeah, and this is still unsafe, because upgrading is inherently, implicitly unsafe. 1. you can upgrade into a vulnerability 2. upgrading often breaks, since newer versions can do things in %pre that make upgrading to a workable state impossible. And have it be equally valid? ;)

2005/11/30, Jeff Spaleta <jspaleta(a)gmail.com&gt;: > > 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.

A couple of months ago, I was under the impression that all the distros were moving in that direction, as Smartpm can handle upgrades to both RPMs and DEBs and can work from all kinds of repositories (apt, yum, urpmi, slack, etc.). Is Smartpm still under consideration for FC5?

I remember someone proposed it in the very early days of extras (before the bugzilla system), but no one ever step up to sponsor it, and I guess the contributor got discouraged .

On 11/26/05, Jeff Spaleta <jspaleta(a)gmail.com&gt; wrote: >On 11/26/05, Deji Akingunola <dakingun(a)gmail.com&gt; wrote: > >>I remember someone proposed it in the very early days of extras >>(before the bugzilla system), but no one ever step up to sponsor it, >>and I guess the contributor got discouraged . > >Please.... find the post me to the post in the fedora-extras-list >archive where the submission request was made, because I certaintly >can't find it. > oh, it was even before people started posting to the list. I'm sure it was submitted for consideration at that time people had to edit the wiki to request for a sponsor. Deji

On 11/26/05, Deji Akingunola <dakingun(a)gmail.com&gt; wrote: > I remember someone proposed it in the very early days of extras > (before the bugzilla system), but no one ever step up to sponsor it, > and I guess the contributor got discouraged . Please.... find the post me to the post in the fedora-extras-list archive where the submission request was made, because I certaintly can't find it.