Aptitud: elija la estrategia de resolución (es decir, actualizar a inestable antes de eliminar)

¿Es posible elegir la estrategia de resolución de "dependencias no satisfechas" de aptitud por defecto (o por lanzamiento)?

Por ejemplo, para que aptitude ofrezca primero una actualización a inestable / install-from-inestable (sid) que la eliminación de paquetes, que tienen dependencias insatisfechas?

Datos de ejemplo de hace unos momentos (estiramiento de Debian 9, con repositorio sid)

Situación inicial presentada a aptitud

# aptitude dist-upgrade
The following NEW packages will be installed:
  libboost-program-options1.67.0{a} 
The following packages will be upgraded:
  libgnuradio-analog3.7.13{b} libgnuradio-audio3.7.13{b} libgnuradio-blocks3.7.13{b} libgnuradio-digital3.7.13{b} libgnuradio-fcd3.7.13{b} libgnuradio-fft3.7.13{b} 
  libgnuradio-filter3.7.13{b} libgnuradio-pmt3.7.13{b} libgnuradio-runtime3.7.13{b} libgnuradio-uhd3.7.13{b} 
10 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,387 kB of archives. After unpacking 2,656 kB will be used.
The following packages have unmet dependencies:
 libgnuradio-analog3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-runtime3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-blocks3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-uhd3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-filter3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-digital3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-fft3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-pmt3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-audio3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed
 libgnuradio-fcd3.7.13 : Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not going to be installed

Aptitude ofreció soluciones para

1. mantener paquetes en la versión actual
2. eliminar algunos paquetes y mantener otros en la versión actual
3. eliminar algunos paquetes, mantener algunos en la versión actual, mantener algunas dependencias sin resolver
4. eliminar todos los paquetes en conflicto, mantener algunas dependencias sin resolver
5. instale la dependencia faltante del canal no prioritario (sid, 100) y realice la actualización de todos los paquetes según lo solicitado

Solución final

The following actions will resolve these dependencies:

     Install the following packages:              
1)     libboost-regex1.67.0 [1.67.0-10 (unstable)]



Accept this solution? [Y/n/q/?] Y
The following NEW packages will be installed:
  libboost-program-options1.67.0{a} libboost-regex1.67.0{a} 
The following packages will be upgraded:
  libgnuradio-analog3.7.13 libgnuradio-audio3.7.13 libgnuradio-blocks3.7.13 libgnuradio-digital3.7.13 libgnuradio-fcd3.7.13 libgnuradio-fft3.7.13 libgnuradio-filter3.7.13 
  libgnuradio-pmt3.7.13 libgnuradio-runtime3.7.13 libgnuradio-uhd3.7.13 
10 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,871 kB of archives. After unpacking 5,837 kB will be used.

Solución válida para mi problema, probablemente no sea uno de estos:

1. Cambie la prioridad del canal sid (/ etc / apt / preferencias) para que tenga el mismo peso que estable / backports; esto cambiaría todo el sistema a inestable
2. Ejecutar aptitude -t sid dist-upgradeya que esto actualizaría todo el sistema desde un canal inestable

Entonces las preguntas son:

• ¿Es posible configurar la aptitud, usar una estrategia de resolución diferente?
• ¿Existe una estrategia que ofrezca primero instalar / actualizar desde inestable que la eliminación excesiva de paquetes? (es decir, actualización de paquetes inestables con dependencias inestables)
• ¿Existe una estrategia que ofrezca primero bajar de categoría a estable que la eliminación excesiva de paquetes? (es decir, para degradar paquetes y dependencias de inestable a estable)