2012/1/7 Thomas Backlund <[email protected]>: > 07.01.2012 09:18, LinuxBSDos.com skrev: >> >> >> True that the user does not and should not care about definitions of an >> orphan, but also, the user should not be put in a situation where he/she >> will have to go hunting for what could or could not break anything. >> > > Well urpme is not at fault. It's doing exactly what it's told. > > It cant solve packager errors. If a packager has forgot a "Requires", > urpmi does not know that. > > The only things --auto-orphans has to go on is: > 1. is the package on the "keep list" such as basesystem -> dont remove. > 2. is the package required by some other package -> dont remove. > 3. is the package manually installed with urpmi/rpmdrake -> dont remove. > 4. is the package the current running kernel -> dont remove. > > > So, if you find your system would be broken (or got broken) by running > urpme --auto-orphans (or the same function in rpmdrake), and you want > it fixed, file bug reports. > > And not against urpmi/rpmdrake, but the package that stopped working.
Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 "orphans". - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. -- wobo
