urpme --auto-orphans

[rodgoslin]

This one has bitten me several times now, and each time was once too many Usually, on removing an application, no longer required, or after doing an update. a popup box will inform that the following list of files are now orphaned and can be removed. Mageia v1 supplied the command line to effect this, as the title, but I note that this is omitted from v2. However, on occasion, after using the auto-orphans command, great swathes of the application base have disappeared, which usually have no possible connection with the application(s) removed. In this, the latest case, I've just tried to edit an odf file, and was a bit surprised that the system opened it in in Okular, rather than the default LibreOffice writer. Swearing under my breath, I closed it down and went off to open LibreOffice, only to find that the entire suite had vanished.. I've now re-installed, but am left wondering what else has disappeared. On one occasion in v1, so much was deleted that it was quicker and more effective to re-install the whole operating system from disc, then wait hours for it all to update, rather than try to work out what had gone, and put it all back.

Rod Goslin

[wobo]

Yes, this is a known issue. urpmi does only know about dependencies. So, if you have updatesd or erased something urpmi lists all packages which were depending on a package not present any more as "orphan", not knowing about what you want to keep or not.

If the list is very short you can easily evaluate if you really want to deinstall. If the list is long you should rather leave it alone. To protect unexperienced users against this trap Mageia has decided to remove the display of the command in the message.

My preferred strategy: I ignore the orphan message. These orphans do no harm to the system.

[oldcodger]

My preferred method for removing single packages is

Code: Select all

 rpm -e --nodeps

Then there are no orphans shown.

[Ken-Bergen]

This one has bitten me several times now, and each time was once too many Usually, on removing an application, no longer required, or after doing an update. a popup box will inform that the following list of files are now orphaned and can be removed.

The command given you lists the packages to be removed and defaults to y/N
As system administrator it's your responsibility to look at the list and decide if you should answer Y.

You say you've been bitten more than once by answering Y without looking but you continue to do so.

[rodgoslin]

Thanks, Wobo. I'd already decided to ignore all calls to delete "orphan files". The point here is that the list of "orphaned files" created from an update should not include whole swathes of the machines installed software. This implies that all the included files are no longer useable, due to the loss of files that they depend on, which again sould not happen.
At the risk of being flamed, I'm pretty sure that this is a fairly recent thing. I've been deleting orphan files, on an automatic basis, for a number of years, and I can't remember this being a problem on Mandriva. And before unleashing the big guns, I dropped Mandriva on trying the mess that was Mandriva 2011, and in all other respects, save that some of my favourite applications don't seem to have made it to Mafgeia's repositories, I'm pretty well satified with my choice. In these days of vast disk capacities, I've no problems in allocating plenty of reserve in the OS partition, so have few worries in watching the disk usage slowly climbing. Unlike the time when I did this for a living and watched in horror as what had at one time been an adequately sized partition inexorably filling up.
To answer Ken Bergens comment, yes, I could go through the list to ascertain which files to ditch and which to keep. But, most of the file names give little or no indication of what they're associated with, and missing one file will bollix the system just as thoroughly as many. Life is too short, particularly at my age, to go back re-doing what the system should have done, and has indicated that it has done, all over again. If the Mageia team are not interested in sorting this out, rather than simply deleting the instruction to remove orphans, they would have been better advised to simply cease to list orphans, and leave the cruft to slowly build up, unseen and unwanted, but of no consequence.

[Ken-Bergen]

At the risk of being flamed, I'm pretty sure that this is a fairly recent thing. I've been deleting orphan files, on an automatic basis, for a number of years, and I can't remember this being a problem on Mandriva.

Although you may not have run into until now the problem has been around since Mandriva first introduced auto-orphans.
If you're short on disk space it's a good tool to see what's not strictly necessary, it can break things that you want but will never break your system rendering it unbootable.

[wobo]

If the Mageia team are not interested in sorting this out, rather than simply deleting the instruction to remove orphans, they would have been better advised to simply cease to list orphans, and leave the cruft to slowly build up, unseen and unwanted, but of no consequence.

Believe me, there have been discussions about this issue, also in Bugzilla. I don't believe that this can be "sorted out" in any way. It is a function of urpmi which does exactly what it is told to do.

As I already wrote, urpmi can not do anything else than judge by the dependencies among the packages. This can be a very short list of 2 or 3 packages but also a very long list of 100 or more. It is expected from the user who uses this tool/command that he knows how to deal with it (like checking the dependencies with the various urpmq commands). Better said: the orphan function as well as removing the orphans is a function for the experienced user. Therefore some suggested already to remove the message about the orphans from the GUI and let it only be displayed on the commandline (this option has my vote). A total removal of the function is not possible because for an experienced system administrator it is an advantage.

[jaywalker]

My impression is the problem of huge lists of orphans has more to do with "sloppy" dependencies in the Mageia (and previously Mandriva) rpm spec files.

Before I discovered what "dependencies" are in reality, I had simply assumed that it meant "those packages without which the subject package cannot function". A cursory sift through a newly generated list of orphans (by that I mean a list which previously had been empty) will often reveal the names of application packages. To me that would be a red warning flag. There are very few applications I can think of which would cease to function in the absence of another application.

I would need to hear a very compelling argument to believe that one application package requires another.

R

[doktor5000]

My impression is the problem of huge lists of orphans has more to do with "sloppy" dependencies in the Mageia (and previously Mandriva) rpm spec files.
[...]
I would need to hear a very compelling argument to believe that one application package requires another.

Sorry, both is just not true.
If you install a package foobar, and it pulls, say 5 libraries with it as dependencies. Then after some time you remove the package foobar, the 5 libraries become orphans. They are still usable standalone without the original package foobar, so not automatically removed. But you can mark them as not being orphans manually.
What i don't understand it, people don't understand the mechanism nor other packaging-related stuff, but complain about those poor orphans.

And one application package requires another - simple example: diskdrake requires mkfs.ext4 (and many others) without it, it can't work.
Or just check how many applications recursively require the coreutils package.

[jaywalker]

Sorry, both is just not true.

Aha! You spotted the flaw in my logic. I hadn't considered the case of operating system utilities which would be invoked by another program. Ironic, really, as I am struggling with a similar problem myself at the moment. I had been focussing so hard on programs which might be invoked if they are present and completely forgot about the sort of case you have pointed out where an important purpose of package A is to make use of package B.

Nevertheless, my reference to application packages was not intended to include OS and third party utilities, but more the sort of grand all-singing, all-dancing application that a user might apply to some hobby or work task. I accept that even narrowing your definition to match mine does not necessarily mean that I am right - just a tiny bit more likely to be right

In my further defence, I made no complaint about dependencies on libraries. These are completely natural and even to be expected, and surely the first case that came to someone's mind when he/she first considered developing a package manager. So no complaints from me about that.

R

[jaywalker]

PS

I was thinking of this example but I couldn't remember the details as it happened some weeks ago.
Rosegarden.
I needed a few midi sequencers/music composition tools to compare and better understand the purpose of programs of this type. I was evaluating a number of music composition/engineering-oriented programs from NON Software and I remembered using and rather liking Rosegarden. I decided to install the Mageia2 package.
Wow!

Additional packages needed < BIG snip> 1.5GB of additional disk space will be used.

OK, it's a big unit and does a lot of work, but wait a minute. I scan down the list of additional packages expecting to see a huge number of libraries but what do I see mixed in among these?
Yet another terminal emulator (don't I have enough already?) a ruby interpreter, Ghostscript and Lilypond!

OK, the ruby interpreter would fall in the same category as your OS utilities I suppose, but in choosing Rosegarden I have zero intention of producing music notation output either on screen or some imaginary printer. If I had that need I would have installed Lilypond myself already.

I have looked at the source for Rosegarden and surprise, surprise; I can build it without any of this kruft. But what do I find in the README? It is nothing less than a justification by the Rosegarden support people for re-designating optional dependencies as mandatory. The reason? Will the package not build without them, will smoke pour from the innards of any PC trying to do this? No, it makes it easier for them to support.

They have made my point far more effectively than I ever could.

DId I install Rosegarden? Not bloomin' likely. If I really feel the need I will build it from source and avoid this new type of dependency hell which is all too often forced upon us.

R

[doktor5000]

Did you try urpmi --no-suggests rosegarden and did it yield different results? And please remember, Mageia is made for the average user,
who cares more about a full-blown system, which is easy to set up with all bells and whistles. Do you really think most people will care how big those packages are (assuming you're on broadband internet with a flatrate)?

And if you do care, then there are ways to slim this down, if you really want to, just ask.

BTW: No need to defend yourself, but for my own defense, i just don't like when people complain about stuff without knowing all the implications and context information.
Proper criticism is always welcome

If you want to know more about packaging quirks and possibilities, just ask.