On Fri, 6 Jan 2012, Thierry Vignaud wrote:
On 6 January 2012 15:53, LinuxBSDos.com <[email protected]> wrote:
This is a well known issue.
To clear out the list you need a deep knowledge of the system to
determine which packages are really not needed anymore.
Lately this --auto-orphans line shreddered my whole system on a fresh
install after the first update, several system services could not
start at next reboot, applications did not run, etc. One of the very
few times I had to re-install because of a bug. Call me newbie or
pussy but until this is not a secure function I will never touch it
again.
Btw, this problem is not unique to Mageia. After I hosed a Debian
installation by running apt with auto-orphans, I vowed never to mess with
orphans again.
The system has to be intelligent enough to know what is or is not an orphan.
It is.
orphan packages are packages that were never directly requested/installed;
they're packages that got installed because they were requested or suggested
by other packages that were explicitely choosed.
Then if you remove the package you explicitely choose, urpmi sees that the
packages that were requested by this one are no more required by anything
and since you never explicitely requested them, it offer to remove them.
Evidently once I've installed package A which requests X, sometimes packages
F, L, and T might subsequently get installed which also need X *and presumably
would have requested it had it not already been installed*. But when I
uninstall
A it orphans X because A is the only package that *requested* it. When F, L,
and T are installed can't all the packages they *would have requested* be marked
whether or not they're already installed? That way a package would be orphaned
only when the last package that needs it is uninstalled? Or am I missing
something?
Dale Huckeby
