Doesn't support installations which require a removal

I can't seem to reproduce on my own...
Do you have any special repository in your sources.list ?

I've just seen that bug on my system (kubuntu jaunty alpha fully updated) without any extra repository in my source.list
maybe the problem only occurs when you have some non default package already installed.

When I tried to install the package, it told me "Remove the package libgd2-noxpm before"
But then, when I click on "OK", Kpackagekit becomes unusable, because the "getting dependencies" dialog stays opened, and both the ok and cancel buttons are disabled. So I can't even try to do what it tells me to do.
The only solution left is to kill the Kpackagekit process.

No, I don't have any additional resource. Maybe it is caused by some nonpreinstall package like langugae support package or something like that?

I don't think this is something wrong with the dependency since I can install amule using apt-get command in terminal.

Actually PackageKit should have a better error message.

Hi Sebastian,

Isn't this a bit of a design flaw in packagekit's naïve separation of privileges then?
Have you spoken to Richard about it?

Thanks,

James

I noticed that this bug also occurs when simply pressing the update notifier icon from within KDE4's panel. If any packages need to be added for supporting an update, KPackageKit blocks it for no apparent reason.

It seems to me that this bug is very visible to all Kubuntu end users, regardless of whether the problem lies with PackageKit or its frontend. Shouldn't its importance be set to High?

I agree with Iwan. I find this of high importance considering Jaunty will be released in a week and system updates requiring package additions and removals fail and are blocked. I have been able to apply the updates using synaptic, but that isn't installed to a system by default, KPackageKit is. When users click on the updates icon they are not going to be expecting to have their package manager block valid updates. Even if the install process isn't perfect on release, the update process at least should be or most users would consider this a downgrade (even from adept 3, at least it could update, if that's all it did right).
On the flip side, thank you for working so hard to make a great package management system. It looks extremely promising!

maybe this is the same bug?

installing digikam konflikts with libgpod4-nogtk which is needed by amarok

Using KpackageKit to install digikam after a fresh install of Kubuntu 9.04RC you are forced to deinstall libgpod4-nogtk, which also deinstalls amarok. After installing digikam libgpod4 is installed instead of libgpod4-nogtk and amarok is installable
again.

probably the same bug. I had to explain my gf how to install digikam from the konsole.. but i doubt this will be fixed before 9.10, or will it?

I don't think so. We are now so close to release and new features aren't implemented once a distribution has been released. I think that we will have to wait to 9.10 to see a fully functional kpackagekit, although it may be impossible to upgrade from 9.04 to 9.10 using it.

If this is not fixed in Jaunty, how will Kubuntu Jaunty users be able to apply updates that require removing or adding packages? How will they be able to install packages with those requirements? This seems like a major, critical regression.

Kubuntu is again less ready then Ubuntu.
I use synaptic in kubuntu. And apt-get from the CLI.

KpackageKit is one of the prominent advertised features in Kubuntu. Not being able to carry out half the things it's supposed to do is really bad for Kubuntu reputation.

This kind of thing gives every user a problem they should solve (even the ones who don't like problem-solving).

It should definitely be a high priority.

Another embarrassing Kubuntu version is released, waiting waiting waiting... this is what every release we told us to do.
I thought that Adept 3.0beta4 was embarrassing enough but with this bug compared to KPackageKit it might become e great software :(

Let's see what they will regress on 9.10, perhaps for Kubuntu 15.10 we will have perfect distro :(

Guys what about stopping giving cd for free and spend money on developing ESSENTIAL tools for every OS like:
1. Networking management
2. Package management

and stop changing programs where the new one does LESS than the previous one, this is called REGRESSION and some people have to start to understand the meaning of that word in software management and taking seriously actions when choosing software portfolio.

I can only repeat what previous posters said: this HAS to be high priority.
either that or adept should be the default package manager until it is solved.

for users that make it here and post a comment it probably isn't such a big problem since they can figure out how to solve it, but i can only imagine how many average users are out there, who are just completely helpless when being confronted with blocked updates etc. and they probably won't report it here either since they don't really know how.

so really for the love of this distro fix this as fast as possible! otherwise i'd propose to remove the slogan "linux for human beings"...

Knowing how Ubuntu works this bug will not be corrected in Jaunty for the stupid hard freeze in code, even for bugs. As Kubuntu is a second class distro, let's hope that it will be corrected in Karmic. I suppose that they will release a new tool to update from Jaunty to Karmic or that they will warn about it being impossible to do in Kubuntu since the upgrade process needs to remove old and incompatible packages.

Karmic upgrade is not screwed as Adept, Synaptic, KPackageKit are not involved, DistUpgrade python scripts are involved.
Anyway Kubuntu's crew has to start thinking and planning a bit better package portfolio that DOES at least all that DOES the previous version and nothing less.

And do not cover under the stupid rule of hard freeze code because this is CALLED serious regression!

I've found another kpackagekit bug. It can't install Meta Packages, such as kubuntu-restrict-extras and ubuntu-desktop. I've opened another bug, but nothing happened after that.

Am i the only person having this problem?

Bug #372256

I just want to say a workaround for people suffering this problem:
1) Open terminal.
2) Run command: $ sudo aptitude update; sudo aptitude full-upgrade

And your system will be fully updated.

It might be this bug that is causing the following erroneous behavior:
- Update notifier comes up with 14 "bug fixes" and 6 "blocked" updates
- I checked from "sudo apt-get update && sudo apt-get dist-upgrade" and it wanted to INSTALL 6 and UPDATE 20
- This included the new kernel version to be installed
KPackageKit was unable to install the 6 blocked updates (doesn't try to install the dependencies). Thus system remains not updated. I wonder how this affects upgrades Jaunty -> Karmic for example... This leads to system not being updated properly and as such is an alarming bug (fails to apply security updates etc.).
Using Kubuntu Jaunty.

I'm seeing this problem with four kernel-related updates showing as blocked when I click on the updater icon.
linux-headers-generic - 2.6.28.11.15 (amd64)
linux-restricted-modules-generic - 2.6.28.11.15 (amd64)
linux-generic - 2.6.28.11.15 (amd64)
linux-image-generic - 2.6.28.11.15 (amd64)

What's particularly odd is that "dpkg -l" reports that all of these packages are ALREADY at this level on my system.

Is there anything in the progress to fix this bug? Just curious how things are going...

I changed the policy in the 0.4.x and 0.5.x branch of PackageKit. It should be part of the next release. An open issue is kpackagekit since it doesn't yet call GetDepends(~installed, IDS_OF_UPDATES) to present the user a list of changes (e.g. additional packages that would be installed). Dantti is working on it.

This bug was fixed in the package packagekit - 0.4.9+20090825-0ubuntu1

---------------
packagekit (0.4.9+20090825-0ubuntu1) karmic; urgency=low

  * New upstream snapshot provding a lot of APT backend improvements:
    - Allow to install updates which require the installation of additional
      packages. Updates depending on the removal of a package are still
      blocked (LP: #342671, LP: #374011, LP: #374011)
    - Warn about the installation of untrusted package (LP: #256245)
    - Don't crash in APT post update hook if system D-Bus daemon isn't
      running (LP: #388623)
    - Don't try to estimate a download progress during cache updating, since
      APT reports only a forth- and backwards running progress. (LP: #348053)
    - Support for python-apt 0.7.12 (LP: #415993)
    - Translated package descriptions
  * debian/patches:
    - Remove ignore_packages_in_conffile (Merged upstream)
    - Remove fix_typo (Merged upstream)
    - Add fix_unicode: Handle the encoding messages via stdin/stdout correctly
      (LP: #396513)
    - Add fix_unicode_debfile: Convert the path of the local file which
      should be installed to the correct encoding (LP: #347327)
  * debian/libpackagekit-qt-dev.install: Fix install location of CMake module.
    Thanks to Sveinung Kvilhaugsvik (LP: #345706)
  * debian/control: Fix spelling of Qt. Thanks to Sveinung Kvilhaugsvik
    (LP: #378419)

 -- Sebastian Heinlein <email address hidden> Tue, 25 Aug 2009 13:03:26 +0200

"Updates depending on the removal of a package are still blocked"
So why was this bug marked as "Fix Released"?

Please fix this problem in Kubuntu 9.04. My customers are not getting a warm fuzzy feeling from Kubuntu when they have to constantly move to the newest release to get some bugs fixed while newer applications get less functionality than previous releases!

This bug has not been fixed. The packagekit update description even says so:

"Updates depending on the removal of a package are still blocked"

Shouldn't this bug remain opened?

I'm using Karmic Alpha 6 updated to 23 Sept 2009 (kpackagekit 0.4.2-0ubuntu2) and it's still not fixed. Today I've found an update for amarok which requires the removal of libtag-extras0 and the installation of libtag-extras1. It was marked as blocked in kpackagekit while I could install it using synaptic.

I'm not certain this is the same issue but I've installed Kubuntu 9.10 twice and each time I try and run the kpackagekit updates even immediately after install it fails saying I don't have priveleges... What gives, that's pretty basic.

hello,

I have right buy new Quad core2 64 bits and installed the Kubuntu Karmic beta1, 2.6.31-11-generic,

and i have many update to do after my first start but Kpackagekit or synaptic wouldn't do while there say i have no privilege.

I am admin and i can only install by APT.

I hope to be fixed soon to can fix a few problem on my new install.

my best and thanks :)

Architecture: amd64
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: packagekit 0.4.9+20090825-0ubuntu5 [modified: var/lib/PackageKit/transactions.db]
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=fr_CH.UTF-8
 LANGUAGE=
ProcVersionSignature: Ubuntu 2.6.31-11.38-generic
Uname: Linux 2.6.31-11-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare syslog

Today I've found two blocked updates in kpackagekit while all the updates were installable in Synaptic (it just needed to remove a package automatically and Synaptic detected it). I'm using an up to date karmic and this bug is certainly not fixed.

Today I've found another blocked update because it needed to uninstall two packages. We are past RC so I don't think this will be solved in Karmic. Maybe it will be solved in Lucid, maybe not, who knows. Seeing that all the efforts in kpackagekit in more than six months have gone in adding some useless animations while this extremely important bug remains open, maybe it will last forever or until we have a 3D multitouch enabled interface or something like that.

I've had it with Kubuntu developers. They break previously working
functions, ignore the impact of their actions on the community and add
unnecessary puff to applications. I've pulled Kubuntu from all of my
systems. Better if the Kubuntu developers go work for Microsoft where they
can be appreciated for the poor quality and unresponsiveness to customer
complaints.

Sincerely,
-Ralph

On Fri, Oct 23, 2009 at 12:26 PM, getaceres <email address hidden> wrote:

> Today I've found another blocked update because it needed to uninstall
> two packages. We are past RC so I don't think this will be solved in
> Karmic. Maybe it will be solved in Lucid, maybe not, who knows. Seeing
> that all the efforts in kpackagekit in more than six months have gone in
> adding some useless animations while this extremely important bug
> remains open, maybe it will last forever or until we have a 3D
> multitouch enabled interface or something like that.
>
> --
> Doesn't support installations which require a removal
> https://bugs.launchpad.net/bugs/342671
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “packagekit” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: kpackagekit
>
> By convention the apt backend doesn't allow to install packages which
> require the removal of other packages before, since PackageKit only has got
> a PolicyKit privilege for removing or installing packages. There is no way
> currently to check if the removal privilege was also granted to the
> installing user.
>
> Original posting:
>
> My system is Kubuntu alpha 6 and have already installed all the available
> updates.
>
> When i was trying to install amule from Kpackagekit, I found out that it
> can't handle package dependency as well as Adept. It told me that a package
> dependency could not be found and told me to remove the package
> libgd2-noxpm. Then I tried to remove libgd2-noxpm and recieved another
> dependency failure saying that Error removing libgd2-noxpm: E:Error,
> pkgProblemResolver::Resolve generated breaks, this may be caused by held
> packages.
>
> P.S. I can install amule by sudo apt-get install amule without any problem.
>

--
Ralph Navarro
Mobile: +1508-287-0190
AIM,Skype: eaglet3d

I second Toni observation in comment #22, how this bug is going to affect upgrades from Jaunty to Karmic?

This bug has nothing to do in the upgrade to karmic process, upgrade is done
by some independent python scripts called from update-notifier-kde tool.

On Fri, Oct 23, 2009 at 04:26:51PM -0000, getaceres wrote:
> Today I've found another blocked update because it needed to uninstall
> two packages. We are past RC so I don't think this will be solved in
> Karmic. Maybe it will be solved in Lucid, maybe not, who knows. Seeing
> that all the efforts in kpackagekit in more than six months have gone in
> adding some useless animations while this extremely important bug
> remains open, maybe it will last forever or until we have a 3D
> multitouch enabled interface or something like that.

This is a bug reporting and not a trolling system. Please read the
reasons above why this is not supported.

> This is a bug reporting and not a trolling system. Please read the
> reasons above why this is not supported.

I concur with your request for people to stop trolling; that is not helpful.

However, I'm slightly confused as to where the reasons for not supporting this are given. Could you please indicate a message #? As a number of people have said, the updating system works fine in synaptic and aptitude?

I would like to echo the comments here and in some of the duplicative bugs that this is a real problem for 'normal' users, eg non-programmers or people who are not overly computer-literate. When I originally posted this myself in Bug #411095 I said:

'When Blocked Updates are available, KPackageKit makes them available in the updater and flags an alert to say that updates are ready. However, it prevents the updates being applied, so the alert stays up forever, defeating the point of having an alert. It is also a potential security problem (although not an actual one) because the user may get fed up with manually checking for new updates and miss a critical one.'

I still see this as being the most important problem caused by this behaviour.

I updated the description of the bug sometime ago. It should provide a brief summary.

You have to make a difference for stable and development versions: It is very unlikely that a security update of a stable release will remove an already installed package. But this will happen quite often in the development version. Nevertheless it is a bug.

I already allowed updates to install further packages in Karmic, which required an advanced dependency resolver. (This is one of the issues that I improved for Karmic if you don't see any progress)

Another problem is the missing preview in the 0.4.x series of PackageKit: We cannot currently preview the removal of packages which would happen during an installation. So removing packages without notifying the user seems to be an even worse issue.

The missing PolicyKit-1 support in KDE blocks the 0.5.x series. In the 0.5.x series it is possible to preview "complex" transactions.

In contrast to Synaptic and aptitude PackageKit is transaction based. So you can queue actions instead of having to apply them once at the sametime. Secondly PackageKit has got a privilege separation: It is possible to have different privileges for installing/removing/updating packages or refreshing the cache.

So in the end this not a pure coding, but a convention and design issue of PackageKit. It would have to even remove some code to allow removal of packages during updates/installations.

I raised the issue once again on the mailing list.

Sebastian,

Thank you for explaining that. The preceding comments make much more sense now.

I see now that all of this area generates a series of compromises.

I'm sorry for my last comment. I know you are doing your job but I was very upset because adept never worked as expected and now kpackagekit isn't working either, so for two years there hasn't been a fully functional package manager in Kubuntu and that's one of the obvious examples of Kubuntu being second in support and lagging behind Ubuntu.
Anyway, I appreciate your work and I understand that this is a complex problem involving all the design of Packagekit (and that Synaptic and Ubuntu in general don't suffer it because they don't use packagekit at all). I heard that KPackage will be replaced by KPackagekit in KDE 4.4, so having more support upstream maybe will solve the problem faster.

"It is very unlikely that a security update of a stable release will remove an already installed package."
I'm not convinced by this assertion. See how many times kernel updates are mentioned in this bug report and in duplicates #347377, #374861, and #395022.

I didn't think it was a great idea to change your package managerment program before it was full tested and had no problem. Adept worked well since last release, but you guys abandoned it and replaced it with a not so much mature program.

Well, this bug was reported about six months ago, but it was not fixed until another release. That was quite depressed, and i thought that was the reason people complained.

Previously it was not possible to install even updates which would require additional packages. So the linux-generic package could not pull in new kernel images. But this is fixed in Karmic.

If you are a volunteer and have got a demanding daily work an half year isn't much time.

For the 0.5 series we have got the possibilty to preview complex changes,but not to handle complex priviliges: If an user is only allowed to install,but not to remove packages he/she is allowed to install packages which remove other packages. This security issue won't be fixed before 0.6

Whenever problems like this arise in immature package management apps,
one can always fall back to apt-get or aptitude, smart, etc. They
work fine.

So, I wonder: where is the wisdom in replacing such mature, stable
systems with ones written from scratch that are intended to look
pretty? Don't Synaptic and Adept sit on top of apt, therefore giving
them a mature, stable base? Apt and aptitude have had many years of
refining. What's wrong with them? If there are some new ideas that
they don't support, why not extend them to support those ideas, rather
than starting from scratch? They probably went through similar
growing pains when they were new, but that was a long time ago. The
whole idea of OSS is to build and stand on the shoulders of giants.
And, as others have mentioned, Ubuntu sails along smoothly with
Synaptic, et al.

Kubuntu will never realize its potential until issues like this are
resolved at a strategic level. (Hardy still seems to be the most
stable, reliable, trouble-free version of Kubuntu!) Forgive me if my
ignorance is showing, but where is the wisdom in all this?

I fully agree with Adam. In addition, I feel his argument is at the crux of an inerrant problem with the decisions that Kubuntu 4.x development made in general. Why rewrite most applications that worked great to begin with? The new releases of Kubuntu applications have broken or missing functionality from the old releases. Had the Kubuntu developers kept the core of each 3.x app and made each work with the additional (not replaced) look and feel of 4.x, then at least users would not have been baited and switched out of comfortable features and structurally important functionality that worked fine in 3.x. ... but I digress ...

For the wheel to have been improved over the years, it had to first keep its round shape; the most basic feature. I propose a new rule for Kubuntu architects whereby any trial app that doesn't leverage an existing and established code base should not be placed into the main stream of default packages until it has proved itself to be as good AND better.

It would be very nice if people could not nominate this for a specific release. It does not speed up anything, indeed it slows down since these false nominations clot the lists of actually fixable issue in those releases. Thanks.

As a sidenode: PackageKit is a common layer on top of the native package managers. The PackageKit backend used in Kubuntu is based on apt. So nobody is rewritting something from scratch. This is nonsense.

Since the currently tracked 0.5 branch of PackageKit won't allow any API changes this issue is verly like to be solved in Lucid+1.

So basically we will have a package manager which will be supported for five years and in this time it will be unable to perform certain update operations. I guess that someone without enough knowledge to execute apt-get or to use synaptic will be very upset seeing how some updates remain blocked during five years.
I propose that, when this happens, an explanation should be included in kpackagekit giving instructions about how to update from console or how to install synaptic.

I'm going to go one further and propose that Kubuntu Lucid not be released with anything less than fully-functional default package manager and upgrade tools (the most fundamental system tool). If this means that Kubuntu is released later than Ubuntu, so be it. It'd be far better to release a working version late than to release a broken version on-time. Debian understands this; why doesn't Kubuntu?

Every version of Kubuntu released after Hardy has been fundamentally broken out-of-the-box in one way or another, whether wireless networking or package management. Now we're being told that Lucid--the next LTS release!--will also be fundamentally broken from the beginning. If this is true, Lucid should be renamed Ludicrous. And if this attitude continues, I think Kubuntu should simply be discontinued. It only serves to give the Ubuntu project and the KDE project bad names. New users will think so poorly of KDE that they will think KDE itself is fundamentally broken, and they'll go to GNOME or back to Windows. This is exactly what they will think if they can't do something as basic as install updates or connect to their wireless router. If Kubuntu isn't going to stop digging its hole created by releasing broken software, it should stop releasing software. Let people use other distros for KDE. Personally, I may return to Debian on my laptop when it comes time to move on from Hardy.

A Synaptic clone in Qt/KDE libs should be started years ago.

One of those has already come and died.

Adam Porter is right. Every release of kubuntu has been fundametally broken in some way: in Intrepid I can't use my bluetooth mouse (and wireless), in Jaunty I can't connect to my school wireless net, in Karmic I can't update some packages with standard application. It's ridiculous. I think Lucid is the last chance - if there will be some major problems out-of-the-box I switch to another distro.

Folks, I 've been trying Kubuntu Karmic for some weeks now and I really like it. There are things still missing and some apps (e.g.: "RKWard" , "Kjots" , "LyX" and "jockey-kde" , "usb-creator-kde", and more) crash(ed) with no obvious reason to an end-user like me (while many of them were working fine under Gnome).

I am trying Kubuntu Lucid Lynx Beta2 (on a Macbook Pro 5,1) right now and it's really difficult. No auto-mount, no cpu freq-scaling, X does not start up automatically ( I have to "startx"). You might be right to point that this piece of hardware isn't what would work out-of-the box with a ?-ubuntu distro. Yet, once the machine boots and a desktop manager works, the user expects that all the goodies of KDE will work as well.

I only had some time to test and wanted to make bug reports... but the auto-bug report tool does not really work. Unfortunately I don't have more free time.

I would really like to see Kubuntu running smooth. And I would wait a bit more than the 29th of April if it is required to have a stable "LTS" release. Keep up the good work!

If this bug isn't going to be fixed this year, then I ask you guys to please bring back Adept.

Even in 9.10 Adept still works awesome! And it's more user-friendly too. For example, if a package fails to install, it gives an explanation to the user what you can do to fix it.
Plus it's more faster and more reliable. It shouldn't be too hard to integrate Adept with System Settings.

PackageKit has some great advantages over Adept, the Debian guys are working on a better APT support at time.
I agree that PackageKit should give more feedback about the stuff it does. As far as I know there already exists support for transporting log messages.
We'll see what the new versions bring.
By the way: The PackageKit version in Ubuntu is outdated. There exists a bugfix release 0.5.8 of the stable branch, which just has not been published on the download page. (It was forgotten...)

Alright, I believe you Matthias :)

One question though: what advantages does it have? Because I don't see any advantages in KPackageKit in comparison to Adept.

You may look at this page: http://packagekit.org/pk-intro.html
Basically, PackageKit allows applications to interact with the package
manager without knowing exactly what it is (yum, apt, zypper etc.).
It basically provides those advantages:
 * Boot time security updates
 * Installing files automatically, e.g. openoffice-clipart
 * Installing new features, e.g. smart-card readers
 * Allowing unprivileged users to install software in a corporate build
 * Opening unknown file formats
 * Removing dependencies for files
It also has a lot of other benefits, check our Richard Hughes summary on
the pkit website.

"PackageKit allows applications to interact with the package
manager without knowing exactly what it is (yum, apt, zypper etc.)"

What advantage has that in Kubuntu, since Kubuntu only uses apt/aptcc as a backend?

"Boot time security updates"

I've never experienced this so far.

"Installing files automatically, e.g. openoffice-clipart"

Adept does that too.

"Installing new features, e.g. smart-card readers"

Adept does that too.

"Allowing unprivileged users to install software in a corporate build"

Ok, Adept can't do that, but when modified a bit, Adept can use Policykit for this too.

"Opening unknown file formats"

As in what?

"Removing dependencies for files"

Adept does that too.

"PackageKit itself is a system activated daemon called packagekitd"

Not true. It runs on the background all the time on my Kubuntu 9.10

Adept does not install plugins for applications or apps which can handle a new file format automatically.
If I write an application, which installs e.g. a plugin automatically from the repositories, I don't want any dependency on APT cause the application should work on Fedora too. The solution is PackageKit.
There is Nautilus integration planned, and on Fedora, PackageKit already does all installing stuff. Also, the Anjuta IDE will use Pkit to install plugins.

> "PackageKit itself is a system activated daemon called packagekitd"
> Not true. It runs on the background all the time on my Kubuntu 9.10
Really? The daemon has a timeout, it will shutdown after some time of inactivity.

Maybe the decision to use PackageKit in Kubuntu was a little bit to early, but basically it was a good choice. If PackageKit gets the missing features, it may replace aptdaemon in Ubuntu too.
But now, please go back to topic. (The advantages and disadvantages of pkit are not the topic of this bug report) I wonder why noone has already complained about the off-topic here.
You can ask a question about this using the "Answers" tab above.

Should be fixed in Maverick. (PackageKit and KPackageKit now do the resolving) Can someone of the bug-reporters please confirm that it works for them too?

It works for me in Maverick.