that is because hunspell-en (which require locales-en) is a suggest of firefox, and rpmdrake install as default the suggested rpm.

Thierry maybe there is a way to not install the suggested one ?

Assignee: bugsquad => thierry.vignaud
Source RPM: urpmi-6.48.1-1.mga2.src.rpm => rpmdrake
Summary: Visually deselected packages installs anyway => Visually deselected packages installs anyway (suggested packages)

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

*** Bug 6445 has been marked as a duplicate of this bug. ***

CC: (none) => LpSolit

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Firefox falls always with libproxy-mozjs
Solution:
# rpm -e --nodeps libproxy-mozjs

CC: (none) => loginov_alex

(In reply to comment #5)
> Firefox falls always with libproxy-mozjs
> Solution:
> # rpm -e --nodeps libproxy-mozjs

what ? this is nothing related to this bug.. (and was fixed by blino..)

*** Bug 8055 has been marked as a duplicate of this bug. ***

CC: (none) => inster.css

This bug is still valid.

For example in rpmdrake search for "opencpn"

This suggests a plugin which rpmdrake wants to install.
Deselect the plugin and the next window shows it will still be installed.

After repeating this several times it is possible to get it to show that only the base package will be installed.

Proceeding with the install then finally shows that both packages are installed anyway.

It is then possible to deselect the plugin and uninstall it using rpmdrake.

CC: (none) => zen25000

*** Bug 10764 has been marked as a duplicate of this bug. ***

CC: (none) => coburn

*** Bug 11029 has been marked as a duplicate of this bug. ***

CC: (none) => oeai

well i didn't select any package, i just wanted to see a list of files that it will install and it wasn't marked anyhow

the mechanics of this can be different, because if package was downloaded in rpm/cache then this can be checked by some service and this can cause the installation process, not only internal markup in drakrpm tasks

still valid mga4 b2+ , drakrpm 6.7
Example: in update, deselected drakxtools, but it got updated anyway.

*** Bug 12959 has been marked as a duplicate of this bug. ***

still valid on cauldron

Still valid as of this morning in Cauldron. Earlier today I had occasion to activate core updates testing to test the gtk=2.0 packages on one of my 32-bit installs of Mageia Beta 3. When I went to update, the libreoffice packages up for testing were also listed and selected. Not wanting to test those, I deselected them. But, when I went to install the packages I wanted, they were still shown to be selected.

CC: (none) => andrewsfarm

This bug MIGHT be worse than you think.

My experience, reported in 

	https://forums.mageia.org/en/viewtopic.php?f=7&t=10571&p=61236&hilit=+extreme+#p61236  

shows that some packages that were about to be included in a "download/install" were not even "checked" (ie in the download box). 


I tested the following (each is part of the whole sequence) on randomly selected target packages:

1.  click on a package line to view it; 
2.  click on a package line, then click on another package line instead;
3.  click on a package line, then view some part of its finer details 
        (eg Details, Dependencies, Files, Changelog);
4.  on another package line, "check" to download, then "uncheck";
5.  on another package line, "check" to download, 
    then click "Apply" to commence download.

Instead of one package (and dependencies) it appears that ALL packages touched seem to be on the notification list.

So, to me, it seems that packages are included for install (at least in the advice box) whether they were "check-box" selected, or not.

I note too that during part of the sequence (described in the Forum) something WAS downloaded, but it happened unexpectedly and fast that I did not get to see what it was.  [I assumed it was "additional detail" about the package being looked at.  I suppose, the point here is that I didn't get to see or approve the download.]

Sorry, I am unclear exactly what "Cauldron" is.  I think I am using only Std official release packages for Mageia5.  (Exception: One or two very useful software were downloaded as rpms, and installed from the HD.)


FYI (for what it's worth)

I am using:
Mageia-5
kernel 4.1.13-desktop-2.mga5
32-bit
Mate

CC: (none) => temporary

"Cauldron" is the set of repositories containing packages for the Mageia version currently under development. Once a version becomes "Official," the contents of Cauldron are moved into the "Official" repositories for that version.

Right now, Cauldron contains packages for Mageia 6. When I posted Comment 16, it contained what was to become Mageia 5 once enough bugs were worked out.

With regard to this particular bug, I haven't seen it in months. For me, it disappeared sometime before the Mageia 5 RC was released.

This bug has re-appeared in Mageia 6. It was discovered as a result of recent tests of the Plasma 5.12.2 update.

To illustrate the problem, I used a VirtualBox Mageia 6 guest that was fully updated, but had not been updated from anything in the testing repositories, including Plasma 5.12.2.

After activating all updates testing repositories, including tainted and 32-bit, I ran Mageia Update from within MCC. A very long list of preselected packages came up, which included, among others, hundreds of packages involved in the Plasma update. 

I decided to simulate a test of a kernel update, using three of the packages on the list, cpupower, kernel-desktop-latest, and kernel-desktop. (Those packages had not yet been assigned to QA, but for purposes of this test that doesn't matter.)

After using the "select all" button to deselect all packages, I took more than usual care to select the three packages above, and ONLY those three packages. But, after clicking on the "update" button, the following message popped up:

The following 8 packages are going to be installed:

- cpupower-4.14.28-1.mga6.x86_64
- kernel-desktop-4.14.28-1.mga6-1-1.mga6.x86_64
- kernel-desktop-latest-4.14.28-1.mga6.x86_64
- lib64okularcore8-17.12.2-1.mga6.x86_64
- lib64qt5core5-5.9.4-1.1.mga6.x86_64
- okular-17.12.2-1.mga6.x86_64
- qtbase5-common-5.9.4-1.1.mga6.x86_64
- task-obsolete-6-126.mga6.noarch

59MB of additional disk space will be used.

61MB of packages will be retrieved.

Is it ok to continue?

The last five packages on the above list are all associated with the pending Plasma 5.12.2 update, but not with a kernel update.

I canceled the update and checked again - none of those last five packages were selected, according to the boxes in the gui. I closed Mageia update and tried again, with the same result.

Checking on real hardware that has been updated to Plasma 5.12.2, and therefore has a MUCH shorter list from testing, and I do not see the problem.

This bug was originally filed under an old Cauldron. Adding MGA6TOO to the Whiteboard, but perhaps the bug should also be re-filed under Mageia 6 to get the needed attention. Be aware that it only adds to the difficulty of properly testing the massive Plasma 5.12.2 update.

Whiteboard: MGA2TOO MGA3TOO => MGA2TOO MGA3TOO MGA6TOO

Interesting!  I wonder if it is the presence of task-obsolete that is making the bug rear its head.  I.e. because it obsoletes something you have installed, it gets automatically selected by MageiaUpdate even if you don't select it.

(In reply to David Walser from comment #20)
> Interesting!  I wonder if it is the presence of task-obsolete that is making
> the bug rear its head.  I.e. because it obsoletes something you have
> installed, it gets automatically selected by MageiaUpdate even if you don't
> select it.

Like maybe it obsoletes the installed versions of the other four packages that I didn't select?

Yes, task-obsolete lists the other four as dependencies.

Well now something else is interesting. If I select just task-obsolete and OK the dependencies, the resultant update list shows task-obsolete TWICE!

I think we're on to something :o)

Mageia 6 64-bit real hardware
MCC -> Update System (AKA MageiaUpdate)

I have seen this problem for a long time, but usually managed to get round it by multiple passes of the selected packages list until the final proposed list was correct. Sometimes this necessitated doing longish lists in sections.
I have only been aware of it when *ordering the pkg list by version*.

The recent huge Qt5-KF5-Plasma updates have brought this to a head, because MageiaUpdate makes them quasi-impossible to apply that way.
If you try to select a block of pkgs of same version, and work through ticking them (accepting offered dependancies), at the end you often see:
- some of those pkgs you selected become UNselected
- wildly irrelevant pkgs outside the wanted section selected
- trying to un-select those:
-- insistence on *installing* their dependant pkgs
-- other pkgs get arbitrarily selected
- trying to re-select wanted pkgs gives the same problems as initially
- if you do manage to coerce the visible tick list to what you want, the final offered pkgs list to update is a nonsense: including pkgs you do not want, omitting some you do want.

I always use rpmdrake's "All Updates" filter to select packages from testing and have not experienced the problems described here. 

I have installed the entire plasma stack update (about 500 packages) in a single transaction without any problems. I have done it three times - twice in VM's (64bit and 32bit) and once on real hardware, without any problems at all.

IMHO MageiaUpdate is the wrong tool to use when "cherry-picking" packages. It is not designed for that purpose.

CC: (none) => jim

It's not fair to say that it's not designed for that purpose when the whole interface is built around allowing you to do that.  It's not designed well for that purpose, as it lets you cherry pick subpackages with the same SRPM, which is wrong, but rpmdrake isn't any better.  MageiaUpdate is just buggy and that's the problem here.

Apparently there's a dragoraUpdate in the manatools package.  It's worth checking to see if it works better too.

I have just discovered that in at least two completed real hardware Plasma updates, when lib64okularcore8-17.12.2-1.mga6.x86_64 (one of the packages pulled in by task-obsolete) was installed, lib64okularcore7-16.12.3-2.mga6.x86_64 was not removed. 

Shouldn't it have been? And if it should have been, is this a bug in Mageia Update, or a Plasma update bug?

This is as it should be. Citing replies i got on dev mail list:
----------------8<-------------------

>> a feature of libification. If library is properly libified, it
>> stays installed until it's not needed by any other pkg and you remove it
>> with 'urpme --auto-orphans'.
Just tested with --auto-orphans (but not accepting)
and it so not want to remove any lib64okularcore
I do not remember history of the *3 and *5 versions, i may have marked then during some upgrade.

But also, it do not want to remove either *7 nor *8
And maybe that is good, at least it is safe.

>> Old libs are removed from mirrors, but not from users' machines.
> Note also that urpmq queries your enabled repos, so this tells you that:
>
> lib64okularcore3-4.12.5-1.mga4
> lib64okularcore5-4.14.3-2.mga5
>
> are not in the Mageia 6 repos, which makes sense are they're from
> Mageia 4 & 5 respectively, and:
>
> lib64okularcore8-17.12.2-1.mga6
>
> is not in your enabled repo - given the version number I guess it
> comes from the KDE update currently in Core Updates Testing, and you
> likely have this repo disabled by default. If you query `urpmq
> --searchmedia testing okularcore`, it should find it too.
Yep

# urpmq --searchmedia testing okularcore --fuzzy
lib64okularcore8
libokularcore8
> Cheers,
> Rémi
Yes i have installed from testing, and it is was disabled.

Now i enabled testing, and try:

# LC_ALL=C urpmq --whatrequires lib64okularcore8
lib64okularcore8
okular
okular-devel

# LC_ALL=C urpmq --whatrequires lib64okularcore7
lib64kookularGenerator_odp15
lib64kookulargenerator_odt15
lib64okularcore7
okular
okular-devel

I raised the red flag because I'm having a printing problem that only seems to involve Okular, not Gwenview or the other Plasma apps that I have tried. Gwenview doesn't have an old library like this, so when Okular did it looked very suspicious. So I asked a few questions.

I raised a bug about the printing problem elsewhere. It's most likely an upstream bug. But, discussion on that doesn't belong here.

Duplicate? :
Bug 22831 - Mageia Control Center - Install packages: Fails to unselect pkgs if task-obsoletes forces to do

(In reply to Morgan Leijström from comment #30)
> Duplicate? :
> Bug 22831 - Mageia Control Center - Install packages: Fails to unselect pkgs
> if task-obsoletes forces to do

I'm not so sure. It could be that we sidetracked ourselves with this task-obsolete observation, and there may be two (or more I suppose) bugs at work.

Testing in my vbox test Plasma 5.8 install.. 

After getting pending approved updates, 6-10 (I forget exactly), I activated testing repositories, and once again tried selecting just those related to the kernel, as I did in Comment 19. This time the vbox additions were there too, so I also selected those. Everything seemed normal. When I clicked on "Update" task-obsolete and the others had not been selected - just the ones I had wanted. Just as was supposed to be.

I canceled it, selected all, then sorted the list by version, highest first, and deselected all. Then I went through the list again, looking for the kernel packages. The vbox additions came up first, and I selected the "-latest" package. Up popped the message about selecting the additions themselves, and the kernel. as should be, but when I OKed that and went back, the box next to the additions was still unchecked. Clicking on that, a box popped up telling me that the "-latest" and the kernel had to be deselected. When I OKed that and went back, BOTH boxes were checked. More checks, and more discrepancies - whatever state was showing in the checkboxes did not agree with the dependencies notices.

Scrolling down to the kernel packages, and the same thing was happening. Neither showed as selected. I clicked on the kernel-latest package, and the window popped up, telling me that the kernel and additions packages had to be deselected - when the boxes indicated they weren't selected at all. And, well, you get the idea.

Selecting all once more, and sorting according to name once more, and selection and deselection worked as it should. And no matter what, if I didn't have task-obsolete selected, it was ignored.

I think my head is starting to hurt.

This misbehavior is still observed with an example package:
systemd-246 (Cauldron).

Before https://bugs.mageia.org/show_bug.cgi?id=27046 was resolved, I do not want systemd version 246 to be installed. I DO want to unchek these updates and sometimes, I believed all 246-related packages were deselected but sometimes they were still listed on confirmation dialog after clicking Update and before really applying.

All I must do was to relaunch mgaonline or rpmdrake.

This is still valid on Cauldron (Mageia 7 too).

Whiteboard: MGA2TOO MGA3TOO MGA6TOO => MGA7TOO

Experienced it again yesterday this way in drakrpm (launced from MCC) in mga7-64:

Decided to try some updates_testing.  Enabled update testing repo, in updated media, selected some packages, but realised i should try less at a time so I selected menu File > Reset the selection.  I observed it said "Selected: 0B" at bottom of its window.

Selected mesa, microcode, firmware. When about to update i noticed a x11- something package was listed but i had not selected it, nor had it asked for to add it like it use to for dependencies.

I closed and reopened drakrpm, selected same packages and now the x11-something was not selected.

So not all is cleared by  File > Reset the selection - seem to remember some dependency it detected in choices made before that action.

Assuming nothing have changed, but ought to be tested.

*** Bug 30434 has been marked as a duplicate of this bug. ***

CC: (none) => LpSolit

rpmdrake version per bug 30434

Source RPM: rpmdrake => rpmdrake-6.32-1.mga8.src.rpm

*** Bug 33708 has been marked as a duplicate of this bug. ***

CC: (none) => mageia

rpmdrake version per Bug 33708

Whiteboard: MGA8TOO => MGA9TOO
Source RPM: rpmdrake-6.32-1.mga8.src.rpm => rpmdrake-6.32-2.mga9.noarch

Ran a software update tonight and this bug appears to still exist on mga9. There was a problem with a bad signature on flightgear-data. I deselected it to no avail (i.e. it attempted to install it again). I ran urpmi --clean and reran the update. The package list showed flightgear-data again and before running the update, I deselected it. Nevertheless, all packages including flightgear-data were redownloaded and updated (flightgear-data was successful this time around).

CC: (none) => varrin