Bug 14594 - Do not show any message about orphans when using rpmdrake / mgaapplet / drakrpm-update
Summary: Do not show any message about orphans when using rpmdrake / mgaapplet / drakr...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: Mageia 6
Assignee: Frédéric Buclin
QA Contact:
URL:
Whiteboard:
Keywords: PATCH
: 11287 (view as bug list)
Depends on: 920
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-18 21:22 CET by Florian Hubold
Modified: 2017-04-03 19:15 CEST (History)
15 users (show)

See Also:
Source RPM: rpmdrake
CVE:
Status comment:


Attachments
remove messages about orphans from rpmdrake, v1 (2.03 KB, patch)
2017-03-25 14:17 CET, Frédéric Buclin
Details | Diff

Description Florian Hubold 2014-11-18 21:22:12 CET
+++ This bug was initially created as a clone of Bug #920 +++

As this was not fixed at all, cloning into a new bug. 

And no - I'm not kidding about the severity. This affects and disturbs a major part of our userbase regularly, mostly novices but also regular and intermediate users do not want to see this. There is no obvious option to disable this, neither within rpmdrake nor via the man page of urpmi.cfg. It should simply default to not show the orphans message via the graphical tools, maybe not even for urpmi.

Users who want this or even regularly use this (e.g. to remove BuildRequires where this works perfectly) are free to use urpm{q,e} --auto-orphans anytime they like.
But please don't annoy users about this by default via the graphical tools.

There's a proposal patch available at https://bugs.mageia.org/show_bug.cgi?id=11287 and there hasn't been any reply yet to the followup for Bug #920 - to describe or at least review the exact target specifications for orphans mechanism - https://bugs.mageia.org/show_bug.cgi?id=12567
Comment 1 Morgan Leijström 2014-11-18 22:22:53 CET
Absolutely the system should not present that alternative by default.

Users get stressed with extraneous info

Especially when system breaks when they follow that advice


Just please quickly comment out the code that make it show that info, and we can go back later some day if we want and if it works then.
Comment 2 Filip Komar 2014-11-19 13:33:17 CET
+1

CC: (none) => filip.komar

Angelo Naselli 2014-12-11 12:14:04 CET

CC: (none) => anaselli

Comment 3 Angelo Naselli 2014-12-11 12:18:27 CET
@Florian could you please add the line 
auto_orphans 0 

into ~/.rpmdrake (user root) and see if rpmdrake shows it again?

It's not a solution, but i would like to understand if that option is managed
or not, then i could provide a better patch than the one on the mentioned bug,
that just delete the warning dialog instead of giving the opportunity to skip it

Thanks.
Comment 4 Angelo Naselli 2014-12-11 13:00:01 CET
hmm looking at the code it should be
auto_orphans 1 

odd...
Comment 5 Florian Hubold 2014-12-11 19:28:22 CET
(In reply to Angelo Naselli from comment #3)
> @Florian could you please add the line 
> auto_orphans 0 
> 
> into ~/.rpmdrake (user root) and see if rpmdrake shows it again?

Tried both 0 and 1 values, and the whole line is removed once rpmdrake is closed.

As I've not used rpmdrake since quite some time, not sure when orphans message should appear there - after every package installation/removal?

orphans message didn't show in both cases, in each try I've installed one package and removed it afterwards again.

CC: (none) => doktor5000

Comment 6 Angelo Naselli 2014-12-11 19:50:58 CET
I think with 0 or without that option the dialog should appear, with auto_orphans 
1 should not. 

If it works as expected, that option can be used to turn ON/OFF the user 
interaction.

It could be used the same method has been implemented for the very first dialog
the one that alerts for the need to connect mirrors to update the packages, e.g.
a check box saying something like "don't show it again" or "manage orphan automatically", WDYT?
Comment 7 Angelo Naselli 2014-12-11 19:52:11 CET
Or adding an option in the option menu...
Comment 8 Morgan Leijström 2014-12-11 20:57:45 CET
I think it should by default neither list orphans, and not even ask.
If it do either, sooner or later some newbie will try before reading.
And most really do not want to try after having read.

IMO it should only list orphans when using a command line switch, which should be described in urpm* --help and other documentation.  Maybe the command line help could refer to the wiki.

______________________________________

I intended to try the setting in ~/.rpmdrake , but i got confused trying to figure out when it shows orphans in the normal case:

First i installed task-kde4 (i only had task-kde4-minimal before) which pulled 212 packages IIRC. I then removed task-kde4 and expected many orphans, but there is only a kernel related package left from earlier update cleaning!?
Then i uninstalled task-kde4-minimal, which made two kde packages orphaned.
Then i also uninstalled task-kde4-handbooks, and now it say nothing about any orphan at all !?
# urpme --auto-orphans shows the three are still there.
So 1) seem to be a bug in urpme about finding orphans only sometimes?
   2) why do I not have many more orphans after removing a recently installed task-* which pulled hundreds of packages?

   Screen copy from terminal:

[root@svarten ~]# urpme -a task-kde4-4
tar bort task-kde4-4.14.3-2.mga5.noarch
tar bort paket task-kde4-3:4.14.3-2.mga5.noarch
      1/1: tar bort task-kde4-3:4.14.3-2.mga5.noarch
                                 #######################################################################

Följande paket:
  kernel-desktop-devel-3.18.0-0.rc7.2.mga5-1-1.mga5.x86_64
behövs ej mera, använd "urpme --auto-orphans" för att ta bort det
[root@svarten ~]# urpme -a task-kde4-m
tar bort task-kde4-minimal-4.14.3-2.mga5.noarch
tar bort paket task-kde4-minimal-3:4.14.3-2.mga5.noarch
      1/1: tar bort task-kde4-minimal-3:4.14.3-2.mga5.noarch
                                 #######################################################################

Följande paket:
  kernel-desktop-devel-3.18.0-0.rc7.2.mga5-1-1.mga5.x86_64
  pam-kwallet-0-0.git20140508.1.mga5.x86_64
  socat-2.0.0-0.b7.3.mga5.x86_64
behövs ej mera, använd "urpme --auto-orphans" för att ta bort dem
[root@svarten ~]# urpme -a task-kde4
tar bort task-kde4-handbooks-4.14.3-2.mga5.noarch
tar bort paket task-kde4-handbooks-3:4.14.3-2.mga5.noarch
      1/1: tar bort task-kde4-handbooks-3:4.14.3-2.mga5.noarch
                                 #######################################################################
[root@svarten ~]# urpme --auto-orphans
För att tillfredsställa beroenden kommer följande 3 paket att tas bort (31MB):
  
(obehövliga paket)
  kernel-desktop-devel-3.18.0-0.rc7.2.mga5-1-1.mga5.x86_64
  pam-kwallet-0-0.git20140508.1.mga5.x86_64
  socat-2.0.0-0.b7.3.mga5.x86_64
Ta bort 3 paket? (j/N) N
[root@svarten ~]#
Comment 9 Angelo Naselli 2014-12-11 21:04:49 CET
Reading the code, auto_orphans 1 option seems to mean managing orphan automatically, so also the list of orphan is hidden if enabled.
Comment 10 Rémi Verschelde 2015-02-24 23:33:13 CET
ROSA added patches to make the auto-orphans check optional (and opt-in) in rpmdrake (and to disable it in urpme, replacing it by a CLI parameter): http://bugs.rosalinux.ru/show_bug.cgi?id=1962

This would be worth looking into as soon as a feature for Mageia 6 IMO.
Manuel Hiebel 2015-03-07 09:18:11 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=920

Comment 11 w unruh 2015-03-07 17:50:28 CET
Nobody new ( and some of us who have used Mandrake/Mandriva/Mageia for over 10 years) know what an orphan IS. It sounds like a program which is no longer needed, which is NOT what it is. Removing all orphans is almost always the wrong thing to do if you want to keep using the machine. For Mageia to even suggest it, whether on the command line or in rpmdrake is thus almost always wrong, confusing,  and a disaster if anyone follows that advice. Far far more of a disaster than the little bit of extra space used by an "orphaned" package.
This suggestion of how to remove all orphans should be removed entirely from all modes of urpm. 

In installing Mageia there are always loads of programs installed that I, and all users of Mageia, will never use (different packages of course). This particular warning makes about as much sense as a warning like "Here is the list of all the packages you have not installed. Run urpmi --auto-install-all to install them." after every running of urpmi. 

The presence of this misleading and disastrous message has been complained about for over 4 years (eg bug 920)-- probably as long as urpme has existed -- and nothing has been done about it. Please get rid of it.
If someone really want to see the orphaned packages, they can apparently always run 
urpmq --auto-orphan
And it would be nice if "orphan" were actually defined somewhere useful
The man pages


In installing Mageia there are always loads of programs installed that I, and all users of Mageia, will never use (different packages of course). This particular warning makes about as much sense as a warning like "Here is the list of all the packages you have not installed. Run urpmi --auto-install-all to install them." after every running of urpmi. 

The presence of this misleading and disastrous message has been complained about for over 4 years (eg bug 920)-- probably as long as urpme has existed -- and nothing has been done about it. Please get rid of it.
If someone really want to see the orphaned packages, they can apparently always run 
urpmq --auto-orphan
And it would be nice if "orphan" were actually defined somewhere useful
The man pages
      --auto-orphans
           Removes orphans.
is not exactly helpful.

CC: (none) => unruh

Florian Hubold 2015-03-07 19:11:34 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=11287

Comment 12 Rémi Verschelde 2015-04-03 12:24:15 CEST
Adding to the Mageia 6 bug tracker, this bug should be in the features list.

Blocks: (none) => 15527

Samuel Verschelde 2015-06-02 10:09:16 CEST

Target Milestone: --- => Mageia 6

Comment 13 Renato Dali 2015-08-06 16:55:45 CEST
This is a problem I may have faced before and probably wrecked a Mandrake install (at least once).

So I agree 100% with doktor5000 evaluation of the major importance of this bug.


Extending on the excellent comment #11 by w unruh, I'd like to disagree with the consensus that the message about orphans should be removed.

I propose that not the message, but the orphan concept is at fault.

As currently defined, removal of an orphan lead to the dangers mentioned in the page https://wiki.mageia.org/en/Removing_packages .

Now, and this I find important, orphans are now a new concept. I believe this has been used for a long time e.g. in linking libraries at compile time: it's important to know what is not used anywhere.

I propose that what is wrong is not the suggestion to remove orphans but that some packages are wrongly labeled as such.

For instance, I understand that if package A needs "libson" and package B needs it, too, "libson" will only become an orphan only if both packages A and B are removed. Currently, if I understood correctly, removal of one package (e.g. B) labels libson as orphaned. That IMHO is the source of our problems.

Removing packages which are not in use is even a great idea wrt security and system maintainability. And I'm not only talking about disk space, but also about processing time... drakconf is somewhat slow on slower CPUs as it is now. I wonder if this can be somehow improved.

Am I wrong in my understanding? Please correct me if so.

Is there a way to check with urpmq (or another tool) which packages were once dependencies and are no longer used by any other package?

That might lead to safer orphan removal process.

Thanks for reading.

PS:

I'm here also because I believe there is an additional localization problem in Portuguese. I unfortunately wasn't able to find the corresponding English dialogue (after a quick search through some documentation pages).

The phrase, translated back to English, is the final one in that "The following packages:... are now orphan" dialogue:

"You wish to remove them." This has a weird tone of something imperative.

I believe the original phrase must be something like "You might wish to remove them." (this BTW translates to "Se desejar, poderá removê-los.") This translation is at least more polite, but also maintains the current problem of leading the user to believe orphan removal is a safe thing.

CC: (none) => mkare

Comment 14 Florian Hubold 2015-08-09 16:47:31 CEST
(In reply to Renato Dali from comment #13)
> Extending on the excellent comment #11 by w unruh, I'd like to disagree with
> the consensus that the message about orphans should be removed.
> 
> I propose that not the message, but the orphan concept is at fault.

Sorry this is the wrong place to ask how this works or to discuss the mechanism. Currently the problem is that everybody using the graphical tools will see the message about orphans regularly. This should simply be removed, period.

Feel free to create a separate bug and try to convince Thierry to change the orphans mechanism, but before you should understand it. I've got no problem with the mechanism, it works pretty well for many use cases if you know how it works. It can e.g. easily be used to clean up BuildRequires on packager systems.
Comment 15 Renato Dali 2015-08-10 17:25:36 CEST
> Sorry this is the wrong place to ask how this works or to discuss the mechanism.

I understand. Thanks for reminding.

=======

> This should simply be removed, period.

This is the safer line of action for now, no doubt.

=======

> ... it works pretty well for many use cases if you know how it works.

I'm going through a though time at work till the end of the 2015, but whenever I can I'll try to get the hang of it. I admit I'm lacking when it comes to repositories and packages...

Thanks for the reply.
Comment 16 Rémi Verschelde 2016-04-05 09:47:57 CEST
Assigning to Thierry, though everyone is free to propose a patch. There's a patch in bug 11287 which comments out the relevant code.

Assignee: bugsquad => thierry.vignaud

Comment 17 Pascal Terjan 2016-04-05 13:59:24 CEST
(In reply to Renato Dali from comment #13)
> For instance, I understand that if package A needs "libson" and package B
> needs it, too, "libson" will only become an orphan only if both packages A
> and B are removed. Currently, if I understood correctly, removal of one
> package (e.g. B) labels libson as orphaned. That IMHO is the source of our
> problems.

This is not true. If something requires it, it will not be marked as an orphan.

The usual source of problem is:
- People remove a KDE app required by task-kde because they don't want this specific app
- This causes task-kde to be removed and they accept it
- All things that were installed becaused required by task-kde are no longer required by anything and considered orphans, leading to removing all of KDE, maybe a good part of X etc...

CC: (none) => pterjan

Comment 18 Pascal Terjan 2016-04-05 14:00:39 CEST
One reason removing orphans is important is the risk of /boot getting full due to old kernels .
Comment 19 Morgan Leijström 2016-04-05 14:17:00 CEST
Orphans functions remove all but latest, IIRC ?
It have happened that failed update of graphics driver made current kernel unbootable.
I always try to keep at least one old, so i always clean kernels manually.
I remember trying fedora(?) and it automatically removed eldest kernels when boot was full - elegant, but that is for a feature request far into the future...
Comment 20 Pascal Terjan 2016-04-05 16:10:59 CEST
(In reply to Morgan Leijström from comment #19)
> Orphans functions remove all but latest, IIRC ?
> It have happened that failed update of graphics driver made current kernel
> unbootable.
> I always try to keep at least one old, so i always clean kernels manually.
> I remember trying fedora(?) and it automatically removed eldest kernels when
> boot was full - elegant, but that is for a feature request far into the
> future...

It keeps the most recent one and the currently running one. That means you will keep two unless you run auto-orphans after having already rebooted onto the new kernel (and presumably being happy enough about it that you are doing something else than rebooting onto the old one).
Comment 21 Marja van Waes 2016-07-12 17:22:16 CEST
Moving to a Mga7 tracker. However, anyone is free to come up with a patch, now: there's a good chance it'll make it into Mga6

CC: (none) => marja11
Blocks: 15527 => 18932
Target Milestone: Mageia 6 => Mageia 7

Comment 22 Thierry Vignaud 2016-07-12 18:09:56 CEST
(In reply to Pascal Terjan from comment #18)
> One reason removing orphans is important is the risk of /boot getting full
> due to old kernels .

One example is this week's bug #18915 where /boot exploded...
Comment 23 w unruh 2016-07-12 19:12:02 CEST
Bad example. Had the old kernels been listed under orphans, and he ran 
the auto-orphan he would have removed all of the working kernels, and been left with a brick. /boot did not explode. He has a tiny /boot, and  two old kernels and one bad new one (bad because he ran out of room). Far more often, the auto-orphans destroys a system rather than helping. And removing all old kernels when installing a new one is a recipe for disaster.
Comment 24 Thierry Vignaud 2016-07-12 22:06:28 CEST
Please.... Check your facts next time. Or read comment #20 above.
Or read the code:
http://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/orphans.pm#n492

urpme --auto-orphans always keep the latest kernel + the currently running one.
Comment 25 Rémi Verschelde 2016-07-13 11:31:51 CEST
As I mentioned somewhere else though (maybe the ML), I don't think that it's necessary to annoy all Mageia users with a list of orphans at each operation just for the sake of the few users that use a specific /boot partition AND made it small AND don't do housekeeping themselves because they're aware that it's made small.

The reports of users breaking there systems (even by their own mistake, but still) using auto-orphans are IMO far more of a concern than this nice-to-have for power users with tiny /boot's.
Comment 26 Rémi Verschelde 2016-07-13 11:32:21 CEST
I'll see if I can propose a patch.
Comment 27 Rémi Verschelde 2016-07-13 11:36:10 CEST
We could also add a `urpme --old-kernels` option if it's the primary usage intended for auto-orphans.
Samuel Verschelde 2016-11-10 10:36:01 CET

Blocks: 18932 => (none)

William Kenney 2016-11-10 12:13:27 CET

CC: (none) => wilcal.int

Comment 28 Filip Komar 2016-11-12 14:31:06 CET
Did anyone tested patch from bug 11287?
Renato Dali 2016-11-12 17:09:58 CET

CC: mkare => (none)

Comment 29 Frédéric Buclin 2017-03-06 19:18:44 CET
*** Bug 11287 has been marked as a duplicate of this bug. ***

CC: (none) => swbutler38

Frédéric Buclin 2017-03-06 19:23:11 CET

Status: NEW => ASSIGNED
Assignee: thierry.vignaud => LpSolit
Target Milestone: Mageia 7 => Mageia 6

Comment 30 Thierry Vignaud 2017-03-07 10:56:19 CET
(In reply to Filip Komar from comment #28)
> Did anyone tested patch from bug 11287?

Disabling orphans altogether in rpmdrake is _not_ a fix...

CC: (none) => thierry.vignaud

Comment 31 Rémi Verschelde 2017-03-07 20:48:38 CET
(In reply to Thierry Vignaud from comment #30)
> (In reply to Filip Komar from comment #28)
> > Did anyone tested patch from bug 11287?
> 
> Disabling orphans altogether in rpmdrake is _not_ a fix...

It can be a design decision. Cf. comment 25 and many others. I think many of us consider that it serves no purpose to show the orphans in rpmdrake after each transaction, especially since it's just an info window and it does not let you actually remove orphans.

I just don't see the point of the feature, so I think it's best we remove it since many voiced that they find it annoying.

We can of course add a setting, and maybe make it opt-in, if there is a real use case for this info dialog. But is there any? If the *only* use case for this feature is to show orphan kernels to avoid /boot from getting full, then it's not the right answer to such use case. Instead, rpmdrake could maybe show a list of orphan kernels when you have e.g. more than 5 of them.
Comment 32 Frédéric Buclin 2017-03-25 14:17:53 CET
Created attachment 9153 [details]
remove messages about orphans from rpmdrake, v1

For the record, urpm::orphans::unrequested_orphans_after_remove() and urpm::orphans::get_now_orphans_gui_msg() are still in use in manatools, so I only removed code from rpmdrake.

You can still use "urpme --auto_orphans" to remove orphans.
Frédéric Buclin 2017-03-25 14:19:12 CET

Keywords: (none) => PATCH
Summary: 'urpme --auto-orphans' message shouldn't be shown when using rpmdrake / mgaapplet / drakrpm-update => Do not show any message about orphans when using rpmdrake / mgaapplet / drakrpm-update

Comment 33 Mageia Robot 2017-04-03 19:15:30 CEST
commit 69b6ad5a9f8e3fc4c1e44d14857787e834386311
Author: Frédéric Buclin <LpSolit@...>
Date:   Sat Mar 25 00:08:13 2017 +0100

    Do not mention orphans when (un)installing packages (mga#14594)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=69b6ad5a9f8e3fc4c1e44d14857787e834386311
Comment 34 Rémi Verschelde 2017-04-03 19:15:47 CEST
Fixed in git.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.