Miguelangel Jose Freitas Loreto escribió: > Luis Rodrigo Gallardo Cruz escribió: >> On Sun, Feb 10, 2008 at 12:26:17PM -0430, Miguelangel Jose Freitas Loreto wrote: >>>> ¿No pasó absolutamente nada después >>>> del 'unmarkauto'? Pega el comando exacto que usaste y lo que te >> ^^^^^^ >>>> contestó, por favor. >>> aptitude markauto dia-gnome ekiga eog esound evince file-roller >> ^^^^^^^^ > >> 'unmarkauto' != 'markauto' > > Tienes razon aui te envio la salidad con 'unmarkauto': > > aptitude unmarkauto dia-gnome ekiga eog esound evince file-roller > [ ... más paquetes que sí se quieren ... ] > ... > Los siguientes paquetes no se usan y se ELIMINARÁN: > at-spi avahi-daemon deborphan dia-common dia-gnome dia-libs ekiga eog > sound evince fast-user-switch-applet festival festlex-cmu festlex-poslex > [ ... Mas paquetes que no se deberían eliminar ... ] > > Cabe destacar, que probe con 'hold' en ves de 'unmarkauto' y > aparentemente funciona. El problema de usar hold es que aptitude no va a instalar actualizaciones para esos paquetes. Leí con más atención el manual y parece que, una vez que aptitude decidió eliminar un paquete, unmarkauto no es suficiente. Si entiendo bien este pasaje: As with any automatic process, there is a potential for things to go haywire. For instance, even if a package was automatically installed to start with, it might turn out to be useful in its own right. You can cancel the ``automatic'' flag at any time by pressing m; if the package is already being removed, you can use Package → Install (+) to cancel the removal and clear the ``automatic'' flag. llamar $ aptitude install <paquetes> es lo que realmente resolvería el problema, pues eso debería marcarlos al mismo tiempo como 'instalado' y 'manual'.
Attachment:
signature.asc
Description: Digital signature