Difficulty downgrading packages with dependencies

Bug #15019 reported by Ryan Garver
70
This bug affects 13 people
Affects Status Importance Assigned to Milestone
synaptic (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

There are some difficulties that I have found with downgrading packages that
have dependencies on the version that I am changing. It would be nice if
downgrades were as easy as upgrades (though I completely understand the
difficulty in this). There are two particular situations that I have been
frustrated with:

1) If the package to be downgraded is depended on at that version by other
packages. This will usually notify you that those packages will be removed
because of breaking dependencies. However it is commonly the case (I'm thinking
*-dev packages) where the dependent package could be downgraded and, as a
result, no package removals would be necessary.

2) If a package being downgraded depends on a package of the current version.
This is even more frustrating. Synaptic will actually just ignore the request
and not provide an explanation. If the depended package were downgraded along
with this package all conflicts would be resolved.

The current method I have been using to get around this is to let synaptic
remove the prackages, and before I commit I'll force the versions to what they
need to be. This is difficult and annoying. I see two ways of fixing this, an
easy to implement but less automated way, and a difficult to implement but
highly optimized way. The easy way is to actually support force version for
packages under a multiple select and try and force all of them not just the last
clicked. The other way would be to check to see when a downgrade is requested
that causes conflicts if there is a set of version changes that will fix the
problem. In either case I think allowing force version on a selection of
packages is a must. This (ideally) would let you even deal with different
packages that have different versions to choose from all collected together.

Hope this is constructive, I enjoy this software and hope you guys keep up the
good work.

Revision history for this message
Michael Vogt (mvo) wrote :

Setting to "minor" because downgrade is not a common operation (and can be dangerous because of side-effects of the post-inst scripts).

Changed in synaptic:
assignee: mvo → nobody
status: Unconfirmed → Confirmed
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

This is quite an issue for me. I wanted to try the new libtheora and had to manually upgrade the versions of libc6 etc.

smb no longer worked with the new versions of libc6 so I wanted to return my system to what it used to be. I tried clicking on the package and "Force Version"ing but that (as was mentioned) wants to remove everything dependent on libc6 - even though they clearly work with the standard Dapper version.

The way I worked around it was to download the deb from the Dapper repo and manually installing with dpkg at the command line (gdebi won't let you downgrade).

Perhaps a "Revert" option, to resync with the repo, could lessen the impact of this bug.

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

it's not really a bug, since downgrading isn't supported at all by the packages - as michael said before. The only reason for this function in synaptic is to fix your system in some rare cases.

Generally manually updating libc is a bad idea. Just recompile the package for your distriubtion.

Revision history for this message
John Toliver (john-toliver) wrote :

So then if I were to install a package and find that the package has a bug for which no patch exists at the time, and I decide I want to go back to what I had earlier that worked, how am I supposed to do this?

Revision history for this message
Mr. Mike (mike-himikeb) wrote :

The big scenario for me on this is when I finally learned/figured-out that the "Proposed" repository is more or less for alpha/beta versions of stuff. Right??
So, when I stopped using those repos, my Ubuntu became way more stable, Suspend starting working properly (proposed kernel is probably the worst choice if you just want to be a user, no?)
So now that I am not using that Repo, I need to downgrade back to the most stable/working versions of stuff.

Comments??

Revision history for this message
John Toliver (john-toliver) wrote : Re: [Bug 15019] Re: Difficulty downgrading packages with dependencies

On Mon, 2008-06-02 at 18:16 +0000, Mr. Mike wrote:
> The big scenario for me on this is when I finally learned/figured-out that the "Proposed" repository is more or less for alpha/beta versions of stuff. Right??
> So, when I stopped using those repos, my Ubuntu became way more stable, Suspend starting working properly (proposed kernel is probably the worst choice if you just want to be a user, no?)

Oh yes I learned that too. It makes sense. I think I attached this
question in reference to an issue with upgrading to a version of
Openoffice with a bug. It didn't come from the 'proposed' though. I
just wanted to know if a clean way to go backwards existed. Anyway I
ended up installing the Non-Ubuntu'ized' version until I found a
suitable workaround.

Revision history for this message
Psy[H[] (vovik-wfa) wrote :

Downgrading package results in marking it's dependencies for removal even if downgrade is not going to make conflict.

Even if it is dangerous to downgrade package it would be nice to have options to keep dependencies in place or downgrade dependencies to resolve conflict, or reinstall dependencies after downgrade. With showing warning.

Because sometimes newer package woks bad, and waiting for another upgrade is not an option. Removing dozens of packages just to downgrade one - just not handy.

Revision history for this message
Sindhu S (sindhu-deactivatedaccount) wrote :

So how exactly does one _mass_ downgrade packages from "newer than those found in archive" to the versions _found_ in archive?

Can someone provide me with the CLI command please? *pleading eyes*

Revision history for this message
John Toliver (john-toliver) wrote : Re: [Bug 15019] Re: Difficulty downgrading packages with dependencies

It's been a while so I don't remember the conversation but I think you turn
off the proposed repos in synaptic and then do the updates. Synaptic will
recognize it is dealing with different versions that what is in the stable
branch and downgrade things back to those version numbers.

I would ask for someone else to verify that but I believe that is what I
did.

2009/9/24 ಸಿಂಧು ಸುಂದರ <email address hidden>

> So how exactly does one _mass_ downgrade packages from "newer than those
> found in archive" to the versions _found_ in archive?
>
> Can someone provide me with the CLI command please? *pleading eyes*
>
> --
> Difficulty downgrading packages with dependencies
> https://bugs.launchpad.net/bugs/15019
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “synaptic” package in Ubuntu: Confirmed
>
> Bug description:
> There are some difficulties that I have found with downgrading packages
> that
> have dependencies on the version that I am changing. It would be nice if
> downgrades were as easy as upgrades (though I completely understand the
> difficulty in this). There are two particular situations that I have been
> frustrated with:
>
> 1) If the package to be downgraded is depended on at that version by other
> packages. This will usually notify you that those packages will be removed
> because of breaking dependencies. However it is commonly the case (I'm
> thinking
> *-dev packages) where the dependent package could be downgraded and, as a
> result, no package removals would be necessary.
>
> 2) If a package being downgraded depends on a package of the current
> version.
> This is even more frustrating. Synaptic will actually just ignore the
> request
> and not provide an explanation. If the depended package were downgraded
> along
> with this package all conflicts would be resolved.
>
> The current method I have been using to get around this is to let synaptic
> remove the prackages, and before I commit I'll force the versions to what
> they
> need to be. This is difficult and annoying. I see two ways of fixing this,
> an
> easy to implement but less automated way, and a difficult to implement but
> highly optimized way. The easy way is to actually support force version for
> packages under a multiple select and try and force all of them not just the
> last
> clicked. The other way would be to check to see when a downgrade is
> requested
> that causes conflicts if there is a set of version changes that will fix
> the
> problem. In either case I think allowing force version on a selection of
> packages is a must. This (ideally) would let you even deal with different
> packages that have different versions to choose from all collected
> together.
>
> Hope this is constructive, I enjoy this software and hope you guys keep up
> the
> good work.
>

--
I've discovered the key to success is to never give up. You either learn
the right way, or you run out of ways to do it wrong. A win/win situation!

Revision history for this message
Jeremiah Rose (jeremiah-aaron-rose) wrote :

I still have this problem when trying to remove (buggy) PPA packages to replace them from mainstream Karmic repos. Synaptic does not handle the situation gracefully, or at all. It disobeys without explanation.

Command-line aptitude, however, does work a bit better. Those looking for a workaround should try:

sudo aptitude install PACKAGE=VERSION

where VERSION is the downgraded version string. aptitude will happily downgrade all the dependent packages, as well.

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for posting this bug.

Does this occur in Lucid?

Changed in synaptic (Ubuntu):
status: Confirmed → Incomplete
Changed in synaptic (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.