# equery depends mit Versionangabe?

## musv

Guten Nachmittag. Ich steck gerade mal wieder in einem Systemupdate. 

Da ich momentan gerade etwas Python programmier, wollte ich eigentlich die neueste Version haben. Jetzt hab ich installiert: 2.7, 3.4, 3.6. Die 3.4 würde ich gern runterhaben, wenn die nicht mehr benötigt wird. 

```
equery d python
```

gibt mir allerdings eine Liste, die so groß ist, dass ich die Infos nicht brauchbar herausfiltern kann. Kann man bei equery d auch irgendwie die Slot-Angabe mit hinzufügen?

----------

## firefly

Es geht aber die Ausgabe ist nicht zu gebrauchen, da es einfach die dependency aus dem ebuild anzeigt.

z.b.

```
$ equery d dev-lang/python:3.5
```

liefert in der ausgabe unter anderem 

```
sys-devel/gdb-7.12.1 (python_single_target_python3_5 ? dev-lang/python:3.5)
```

Aber ich habe python 3.5 überhaupt nicht installiert bzw. ist gdb damit nicht gebaut:

```
$ eix -I dev-lang/python

[I] dev-lang/python

     Available versions:  

     (2.7)  2.7.12 ~2.7.13

     (3.4)  3.4.5(3.4/3.4m) ~3.4.6(3.4/3.4m)

     (3.5)  ~3.5.3(3.5/3.5m)

     (3.6)  ~3.6.1-r1(3.6/3.6m)

       {-berkdb build doc examples gdbm hardened ipv6 libressl +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC="uclibc"}

     Installed versions:  2.7.12(2.7)(22:34:58 07/12/16)(gdbm ipv6 ncurses readline sqlite ssl threads tk wide-unicode xml -berkdb -build -doc -examples -hardened -libressl -wininst ELIBC="-uclibc") 3.4.5(3.4)(22:36:10 07/12/16)(gdbm ipv6 ncurses readline sqlite ssl threads tk xml -build -examples -hardened -libressl -wininst ELIBC="-uclibc")

     Homepage:            https://www.python.org/

     Description:         An interpreted, interactive, object-oriented programming language
```

```
$ cave resolve -1 gdb

Done: 4364 steps               

These are the actions I will take, in order:

r   sys-devel/gdb:0::gentoo 7.12.1 to ::installed replacing 7.12.1

    client lzma -multitarget nls python server -vanilla xml (-test) PYTHON_SINGLE_TARGET: -python2_7 python3_4 (-python3_5) PYTHON_TARGETS: python2_7 python3_4 (-python3_5) build_options: symbols=split -dwarf_compress -optional_tests -trace work=tidyup

    Reasons: target, !<sys-devel/gdb-7.10-r1[nls] from sys-libs/binutils-libs-2.25.1-r2:0::installed
```

Mit paludis gibt es eine möglichkeit die pakete anzuzeigen, welche ein bestimmtes paket wirklich als abhängigkeit hat als es installiert wurde.

cave print-dependet-ids

ich habe bei mir ein alias für dieses command erstellt:

```
alias cave-print-dependents='cave print-dependent-ids -f '\''%c/%p%:%s\n'\'''
```

Um beim gdb beispiel zu bleiben:

```
$ cave-print-dependents dev-lang/python:2.7 | grep sys-devel/gdb
```

liefert keine Ausgabe.

```
$ cave-print-dependents dev-lang/python:3.4 | grep sys-devel/gdb

sys-devel/gdb:0
```

hier kommt eine ausgabe da gdb nur gegen python 3.4 gebaut wurde.

Für ein nicht installierte paket version kommt folgendes

```
$ cave-print-dependents dev-lang/python:3.5

Error:

  * In program cave print-dependent-ids -f %c/%p%:%s\n dev-lang/python:3.5:

  * Found nothing suitable matching 'dev-lang/python:3.5' (paludis::cave::NothingMatching)
```

Eventuell ist die Ausgabe hilfreicher wenn du einfach versucht python:3.4 zu deinstallieren.

----------

## Josef.95

 *firefly wrote:*   

> Mit paludis gibt es eine möglichkeit die pakete anzuzeigen, welche ein bestimmtes paket wirklich als abhängigkeit hat als es installiert wurde.

 

Ja, mit portage kann man sich diese Liste (sprich die aktuell tatsächlich vorhandenen Abhängigkeiten) via

emerge --depclean --verbose package 

ausgeben lassen. Wichtig ist hier die Kombination --depclean --verbose package

@musv

"equery depends paket" ist für dein Vorhaben nicht wirklich gut geeignet. Beachte das "equery d paket" die (je nach gesetzten Useflags, verwendete version usw) möglichen Abhängigkeiten ausgibt, nicht die aktuell tatsächlich vorhandenen.

Um die aktuell tatsächlich vorhandenen reverse Dependencies eines installierten Pakets aufzulisten nutze besser emerge --depclean paket in Kombination mit --verbose.

Für dein python:3.4 dann zb via 

```
emerge -pvc python:3.4
```

 Schaue dort dann unter

dev-lang/python-3.4.6 pulled in by:

...

...

----------

## musv

 *Josef.95 wrote:*   

> Um die aktuell tatsächlich vorhandenen reverse Dependencies eines installierten Pakets aufzulisten nutze besser emerge --depclean paket in Kombination mit --verbose.
> 
> Für dein python:3.4 dann zb via 
> 
> ```
> ...

 

Bringt leider nichts. Ich hab Python3_4 aus den PYTHON_TARGETS in der make.conf rausgenommen und emerge -pvc hinterher geschickt. Jetzt krieg ich 'ne Liste von gefühlt 150 Paketen, die Python:3.4 benötigen - also alle Pakete mit Python3-Support.

----------

## Josef.95

 *musv wrote:*   

> [...]
> 
> Bringt leider nichts. Ich hab Python3_4 aus den PYTHON_TARGETS in der make.conf rausgenommen und emerge -pvc hinterher geschickt. Jetzt krieg ich 'ne Liste von gefühlt 150 Paketen, die Python:3.4 benötigen - also alle Pakete mit Python3-Support.

 

Hm, hast du python3_4 bisher nur aus den PYTHON_TARGETS und PYTHON_SINGLE_TARGET Variablen herausgenommen, oder die betroffenen Pakete auch  tatsächlich schon damit gebaut?

Hier bei mir (ich hab python2_7 und python3_5) funktionierte das entfernen von python:3.4 (auf einem ~amd64 Testsystem) einwandfrei. Aber nungut, kommt sicherlich auch drauf an was man für Pakete installiert hat.

Würde mich aber interessieren welche Pakete tatsächlich noch zwingend python:3.4 benötigen.

Tatsächlich bauen, und dann ein --depclean sollte normal fein funktionieren.

Oder hast du ein stable amd64 System? (beachte, auf stable sind höhere python_single_target_python und python_targets_python Useflags zum teil noch maskiert).

----------

## musv

Aufgrund der großen Anzahl der Pakete hab ich es nicht neu gebaut. Das kommt dann blöd, wenn ich Python3.4 runterschmeiß, kann den ganzen Schwall an abhängigen Paketen neu installieren und merk dann, dass ein großer Teil noch immer zwingend abhängig von Python3.4 ist. 

Ich kann mich halt dunkel daran erinnern, dass es ein paar Pakete in der Abhängigkeitsliste gab, die noch nicht mit >Python3.4 funktionierten. Aber das Durchwühlen der Abhängigkeiten ist halt wie die Suche im Heuhaufen.

----------

## Josef.95

Ja ok, dann verstehe ich aber deine Aussage  *musv wrote:*   

> Die 3.4 würde ich gern runterhaben, wenn die nicht mehr benötigt wird.

  nicht ganz :-/

Ohne die python3_4 Abhängigkeiten tatsächlich auszubauen ist klar das --depclean python:3.4 nicht entfernen tut.

Sprich, nur in die config (make.conf) schreiben reicht nicht, man muss die Änderung auch tatsächlich bauen.

Momentan hab ich den Eindruck, das du python:3.4 gern runterhaben möchtest, aber keine Lust hast deren Abhängigkeit tatsächlich auszubauen?! :)

Nungut.. :)

/edit: Hier würde es mit dem Vorschlag so ausschauen (wenn man die python3_4 Abhängigkeiten denn tatsächlich ausgebaut hat): 

```
# emerge -avc python:3.4

Calculating dependencies... done!

>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 dev-lang/python

    selected: 3.4.6 

   protected: none 

     omitted: 2.7.13 3.5.3 

All selected packages: =dev-lang/python-3.4.6

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No]
```

----------

## musv

Ich hol mal das Thema wieder hoch. Hab jetzt mal die Liste analysiert, die mir equery depends so ausspuckt.

```
app-doc/doxygen                         - 2.7   3.4   3.5

app-office/libreoffice                  -       3.4

dev-libs/botan                          - 2.7   3.4

dev-libs/libevdev                       - 2.7   3.4   3.5

dev-libs/libnl                          - 2.7   3.4   3.5

dev-libs/libpeas                        -       3.4   3.5

dev-python/backports-ssl-match-hostname - 2.7   3.4

dev-python/cached-property              - 2.7   3.4         3.6

dev-python/hypothesis                   - 2.7   3.4         3.6

dev-python/libvirt-python               - 2.7   3.4

dev-python/pycparser                    - 2.7   3.4         3.6

dev-python/qscintilla-python            - 2.7   3.4   3.5

dev-qt/qtdeclarative                    - 2.7   3.4   3.5

dev-util/eric                           - 2.7   3.4   3.5

media-gfx/hugin                         - 2.7   3.4   3.5

media-libs/gexiv2                       - 2.7   3.4   3.5

media-libs/libepoxy                     - 2.7   3.4   3.5

net-libs/libsoup                        - 2.7   3.4   3.5

net-news/liferea                        -       3.4   3.5

sys-firmware/seabios                    - 2.7   3.4   3.5
```

Fazit: Momentan scheint man bei Gentoo mindestens die 2.7 und die 3.4 benötigen. Libreoffice benutzt sogar ausschießlich die 3.4.

----------

## Christian99

nein, das stimmt so nicht.

Ich habe auf meinen system kein python-3.4, nur 2.7, 3.5, 3.6

libreoffice geht mit python-3.5, hatte noch keine probleme.

Der weg ist tatsächlich python3_4 aus den PYTHON_TARGETS zu entfernen.

dann 'emerge -uDN world'. wenn er meckert, dann versuche ich erst mal stückweise einzelne pakete neu zu bauen.

----------

## Josef.95

Jo, kommt auch mit auf die Version mit drauf an. Die aktuelle testing libreoffice-5.4.2.2 Version baut mit aktuell allen im Tree verfügbaren Python Versionen, von 2.7 bis 3.6

Schau am besten direkt im Ebuild 

```
grep PYTHON_COMPAT `equery w libreoffice-5.4.2.2`

PYTHON_COMPAT=( python2_7 python3_{4,5,6} )
```

 oder zur allgemeinen Übersicht auch mal via eix 

```
eix -e libreoffice

* app-office/libreoffice

     Available versions:  5.2.7.2 (~)5.4.2.2 **5.4.9999 **9999 {bluetooth +branding coinmp collada +cups dbus debug eds firebird gltf gnome googledrive gstreamer +gtk gtk3 java jemalloc kde libressl mysql odk pdfimport postgres quickstarter telepathy test vlc ELIBC="FreeBSD" LIBREOFFICE_EXTENSIONS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6" PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}

     Homepage:            https://www.libreoffice.org

     Description:         A full office productivity suite
```

----------

## Christian99

stimmt natürlich. ich hab vergessen, dass ich system mit testing versionen habe.

Möglicherweise haben dann einige stable pakete nur python3_4 und nichts höheres

----------

