# [libinput] Installation manuelle requise (resolu)

## sebB

Salut,

Petite question du dredi

J'ai envie d'essayer libinput.

Donc dans mon make.conf je vire evdev et synaptics et je remplace par libinput

```
INPUT_DEVICES="libinput"
```

Je lance un emerge -uDNv @world et là il veut rien me mettre à jour.sauf plasma

```
[ebuild   R    ] kde-plasma/plasma-desktop-5.9.5:5::gentoo  USE="fontconfig pulseaudio -appstream -debug -gtk2 -gtk3 -handbook -ibus -legacy-systray -qt4 -scim -semantic-desktop {-test}" INPUT_DEVICES="-evdev* -synaptics*" 0 KiB

```

J'y vais donc à la bourrin en lancant un

```
emerge -uDNvp --with-bdeps=y --backtrack=300 --changed-deps=y --keep-going=y @world

```

Même chose

Pourtant si je lance un emerge -pv xorg-drivers

```
[ebuild   R    ] x11-base/xorg-drivers-1.19::gentoo  INPUT_DEVICES="libinput* -acecad -aiptek -elographics -evdev* -fpit -hyperpen -joystick -keyboard -mouse -mutouch -penmount -synaptics* -tslib -vmmouse -void -wacom"
```

Autre test avec INPUT_DEVICES="evdev synaptics libinput"

Calculating dependencies... done!

```
[ebuild   R    ] x11-base/xorg-drivers-1.19::gentoo  INPUT_DEVICES="evdev libinput* synaptics -acecad -aiptek -elographics -fpit -hyperpen -joystick -keyboard -mouse -mutouch -penmount -tslib -vmmouse -void -wacom"
```

Donc là il en veut bien 

Avant de faire les maj manuellement quelqu'un aurait-il un debut d'explications?

MerciLast edited by sebB on Sat Jul 08, 2017 8:34 am; edited 1 time in total

----------

## Mr. T.

Mon hypothèse est que Portage ne gère pas obligatoirement les dépendances "post-installation" d'un progiciel.

 *devmanual wrote:*   

> The PDEPEND variable specifies dependencies that should be merged after the package, but which may be merged at any time, if the former is not possible.

 

```
PDEPEND="

    input_devices_libinput?    ( x11-drivers/xf86-input-libinput )

"
```

```
COMMON_DEPEND="

    input_devices_synaptics? ( x11-drivers/xf86-input-synaptics )

"

RDEPEND="${COMMON_DEPEND}

"

DEPEND="${COMMON_DEPEND}

    input_devices_evdev? ( x11-drivers/xf86-input-evdev )

"

```

N.B n°1 : Les extraits de code ne sont pas exhaustifs !

N.B n°2 : INPUT_DEVICES est une USE_EXPAND flag ! INPUT_DEVICES="libinput" devient input_devices_libinput après interprétation.

helecho.

----------

## sebB

Bon en fait le samedi on est plus reposé.

Le problème venait du fait que je n'avais pas xorg-server dans mon world vu qu'il dépendait de plasma.

Et comme plasma n'a pas de dépendances avec libinput, il voulait tout simplement me virer xorg...

----------

## Mr. T.

 *SebB wrote:*   

> Le problème venait du fait que je n'avais pas xorg-server dans mon world vu qu'il dépendait de plasma.
> 
> Et comme plasma n'a pas de dépendances avec libinput, il voulait tout simplement me virer xorg...

 

Pourrais tu expliquer ce que signifie "virer xorg" ?

La commande convenable aurait été : 

emerge --ask --changed-use --deep @world

emerge -aUD @world

Le problème ne vient pas du fait que xorg-server soit installé comme une dépendance de plasma-desktop.   :Twisted Evil: 

 *man emerge wrote:*   

>  --complete-graph [ y | n ]
> 
> This  causes emerge to consider the deep dependencies of all packages from the world set. With this option enabled, emerge will bail out if it deter‐
> 
>               mines that the given operation will break any dependencies of the packages that have been added to the graph. Like  the  --deep  option,  the  --com‐
> ...

 

Les informations soulignées indiquent que les options --complete-graph et --deep @world sont semblables.

Édition : 3. emerge -aUD --with-bdeps=y @world

----------

## sebB

 *Quote:*   

> Pourrais tu expliquer ce que signifie "virer xorg" ? 

 

Virer xorg....

 *Quote:*   

> Le problème ne vient pas du fait que xorg-server soit installé comme une dépendance de plasma-desktop

 

Si

 *Quote:*   

> Mon hypothèse est que Portage ne gère pas obligatoirement les dépendances "post-installation" d'un progiciel. 
> 
> 

 

Rien compris

 *Quote:*   

> La commande convenable aurait été : 
> 
> emerge --ask --changed-use --deep @world 
> 
> emerge -aUD @world

 

https://forums.gentoo.org/viewtopic-p-8087582.html#8087582

----------

## Mr. T.

Tu ne reconnais pas la différence entre la commande exécutée et la commande qu'il aurait fallu exécuter !

emerge --update --deep --newuse --verbose @world

emerge --ask --changed-use --deep @world

On souhaite mettre à jour le système suite à l'activation d'une USE flag. On remarquera que cette USE flag est activée par l'utilisateur.

En conséquent, il est superflu d'installer des logiciels plus récent pour effectuer la manipulation précédente : içi, l'option --update est inutile !

Enfin, l'option --newuse est partiellement inadaptée au contexte car on sait que la modification de la USE flag n'est pas définie par 

la configuration par défaut du système. Par contre, l'option --changed-use est adaptée lorsque la USE flag est modifiée par l'utilisateur.

 *SebB wrote:*   

>  *helecho wrote:*   Pourrais tu expliquer ce que signifie "virer xorg" ? 
> 
> Virer xorg.... 

 

Aucun commentaire !

 *SebB wrote:*   

>  *helecho wrote:*   
> 
> Mon hypothèse est que Portage ne gère pas obligatoirement les dépendances "post-installation" d'un progiciel. 
> 
> Rien compris 

 

Après réflexion, l'hypothèse semble erronée. En fait, xorg-drivers n'est pas un progiciel mais un méta-progiciel. En fait, je ne saisis pas comment la notion de 

PDEPEND pourrait correspondre aux dépendances pouvant être potentiellement établies entre les logiciels spécifiés par xorg-drivers. Il me semble probable qu'il n'y ait aucun lien.

Remarque : le terme "progiciel" peut être inadéquatement employé, c'est une remise en question terminologique, arrg !

----------

## sebB

 *Quote:*   

> Tu ne reconnais pas la différence entre la commande exécutée et la commande qu'il aurait fallu exécuter ! 

 

Explique en quoi ta commande aurait solutionné mon problème?

Allez je t'aide. Ca donne les même résultats.

 *Quote:*   

> Aucun commentaire ! 

 

Fait l'arbre généalogique.

 *Quote:*   

> Après réflexion, l'hypothèse semble erronée. En fait, xorg-drivers n'est pas un progiciel mais un méta-progiciel. En fait, je ne saisis pas comment la notion de 
> 
> PDEPEND pourrait correspondre aux dépendances pouvant être potentiellement établies entre les logiciels spécifiés par xorg-drivers. Il me semble probable qu'il n'y ait aucun lien. 
> 
> Remarque : le terme "progiciel" peut être inadéquatement employé, c'est une remise en question terminologique, arrg !

 

Toujours rien compris.

Fait attention, tu as mal défini ton clavier. Tu as les " ! " qui remplacent les " . "

----------

## Mr. T.

J'ai montré (déduis) que ton affirmation est fausse et qu'en suivant les conventions d'application, la commande (laquelle !?) est inadaptée au contexte d'utilisation.

J'essaye de comprendre pourquoi Portage (emerge) ne considère pas systématiquement les modifications engendrées par INPUT_DEVICES="libinput".

Édition : 

 *helecho wrote:*   

> Après réflexion, l'hypothèse semble erronée. En fait, xorg-drivers n'est pas un progiciel mais un méta-progiciel. En fait, je ne saisis pas comment la notion de
> 
> PDEPEND pourrait correspondre aux dépendances pouvant être potentiellement établies entre les logiciels spécifiés par xorg-drivers. Il me semble probable qu'il n'y ait aucun lien. 

 

Je ne trouve pas d'équivalence entre la notion de PDEPEND (ou sa définition) et l'utilisation de la variable PDEPEND du fichier xorg-drivers-1.19.ebuild.

 *devmanual wrote:*   

> Post-Merge Dependencies
> 
> The PDEPEND variable specifies dependencies that should be merged after the package, but which may be merged at any time, if the former is not possible. This is sometimes used for plugins that have a dependency upon the package being merged. Generally PDEPEND should be avoided in favour of RDEPEND except where this will create circular dependency chains.
> 
> 

 

helecho.Last edited by Mr. T. on Sat Jul 08, 2017 3:50 pm; edited 1 time in total

----------

## sebB

 *Quote:*   

> J'ai montré que ton affirmation est fausse et qu'en suivant les conventions d'application, la commande (laquelle !?) est inadaptée au contexte d'utilisation.

 

Quelle affirmation?

Sinon le reste de la phrase toujours rien compris.

 *Quote:*   

> J'essaye de comprendre pourquoi Portage (emerge) ne considère pas systématiquement les modifications engendrées par INPUT_DEVICES="libinput".

 

Bin si, c'est bien mon cas.

----------

## Mr. T.

Tu n'as pas encore compris !? Bon, tant pis !

----------

## sebB

A bin non. Faut aller au bout des choses pour une fois

Puisque tu affirmes que ce que je dis et ce que j'ai fait n'est pas bon explique moi.

Comme je suis sympa je te poste mon @world (j'ai bien enlevé xorg-server qui n'y était pas au départ)

```
app-arch/lzop

app-arch/p7zip

app-arch/unrar

app-office/calligra

app-office/skrooge

app-portage/eix

app-portage/elogv

app-portage/genlop

app-portage/gentoolkit

app-portage/layman

app-text/calibre

kde-apps/ark

kde-apps/dolphin

kde-apps/gwenview

kde-apps/kate

kde-apps/kde-l10n

kde-apps/konsole

kde-apps/okular

kde-apps/spectacle

kde-misc/plasma-applet-redshift-control

kde-misc/skanlite

kde-plasma/plasma-meta

media-gfx/krita

media-sound/clementine

media-video/mkvtoolnix

media-video/smplayer

sys-apps/hdparm

sys-boot/grub

sys-fs/dosfstools

sys-fs/ntfs3g

sys-kernel/genkernel-next

sys-kernel/gentoo-sources

sys-kernel/linux-firmware

www-client/qupzilla

x11-misc/redshift
```

Dis moi si t'as besoin d'autres infos

----------

## Mr. T.

Je te laisses méditer pour percer le mystère !   :Laughing: 

----------

## sebB

En fin de compte t'en sais rien...

Allez on va gentiment laisser tomber ce topic dans les profondeurs du forum (pas de smiley)

----------

## Mr. T.

On est revenu à l'interrogation initiale : la commande initiale aurait vraisemblablement dû activer la USE flag input_devices_libinput.

Je n'ai pas trouvé l'explication. Peut-être faut il saisir le fonctionnement de Portage ? J'ai lu superficiellement la documentation de emerge mais sans trouver la réponse.

bug 577292

----------

## thican

Bonjour,

Je pense que ça n’a pas fonctionné car il se peut effectivement que le paquet ne soit pas une dépendance ;  me concernant, j’ai rajouté x11-base/xorg-x11 dans mon @world, mais x11-base/xorg-server est suffisant.

Ensuite, concernant l’utilisation de l’option "--update", si, ça fonctionne quand il s’agit de mettre à jour un ensemble ("set") :

man emerge(1)

 *Quote:*   

> set
> 
> A set is a convenient shorthand for a large group  of  packages.
> 
> […]
> ...

 

C’est d’ailleurs explicitement donné comme exemple dans l’option "--depclean"

 *Quote:*   

> --depclean (-c)
> 
> Cleans the system by removing packages that are  not  associated
> 
> with  explicitly merged packages. Depclean works by creating the
> ...

 

Du coup, je pense qu’il est nécessaire de voir si un "depclean" ("emerge --ask --depclean") ne serait pas nécessaire pour nettoyer le système, et voir si Xorg restera. Dans le cas contraire, le rajouter avec "--noreplace" (comme expliqué dans "--depclean").

Je viens de tester sur mon système, la modification de cette variable est bien prise en compte. Peut-être y a-t-il des entrées dans package.use qui écrase cette modification ?

J’en profite aussi pour dire que les USE flags "evdev" et "libinput" sont utiles à certains paquet (de plus, dev-libs/libinput a une dépendance "statique" pour dev-libs/libevdev).

----------

## Mr. T.

SebB a eu raison d'installer xorg-server. L'option --update serait superflue si elle était utilisée en lien avec un seul paquet.

A mon avis, l'origine du problème provenait de la USE flag X ; elle aurait due être activée globalement. Vraisemblablement, 

INPUT_DEVICES a été considéré par Portage mais il n'y avait aucun logiciel installé qui la supportait.

 *Xorg Guide wrote:*   

> If the suggested settings does not work, emerge the x11-base/xorg-drivers package [...]

 

Édition : xorg-drivers était installé, supportait la USE flag input_device_libinput, elle-même activée à cause de INPUT_DEVICES="libinput".

Je crois qu'il faudrait connaître l'algorithme de résolution des dépendances et l'algorithme de mise à jour pour déterminer l'étape relative au problème.

Je vais tenter ma chance : ouvrir un nouveau fil de discussion pour résoudre le mystère.

helecho.

----------

## Mr. T.

Thican, il s'agit explicitement de savoir si xorg-drivers est inclu dans l'arborescence des dépendances créée par Portage lors de la mise à jour.

 *thican wrote:*   

> Je pense que ça n’a pas fonctionné car il se peut effectivement que le paquet ne soit pas une dépendance [...]
> 
> Du coup, je pense qu’il est nécessaire de voir si un "depclean" ("emerge --ask --depclean") ne serait pas nécessaire pour nettoyer le système, et voir si Xorg restera. [...]

 

D'après la Foire Aux Questions, Portage ne met pas à jour tous les paquets. Malheureusement, la réponse est évasive.

Édition : Je me sens incapable de continuer le développement de ce sujet sans aide.

helecho.

----------

## Mr. T.

Le paquet kde-plasma/plasma-meta installé dans l'ensemble "world" a installé (indirectement ?) le paquet xorg-drivers (emerge -pv plasma-meta | grep xorg).

 *sebB wrote:*   

> Bon en fait le samedi on est plus reposé.
> 
> Le problème venait du fait que je n'avais pas xorg-server dans mon world vu qu'il dépendait de plasma.
> 
> Et comme plasma n'a pas de dépendances avec libinput, il voulait tout simplement me virer xorg...

 

```
helecho $ qdepends -p x11-base/xorg-server

x11-base/xorg-server-1.19.3: >=x11-base/xorg-drivers-1.19

helecho $ qdepends -p x11-base/xorg-drivers | tr ' ' '\n' | grep -w x11-base/xorg-server

>=x11-base/xorg-server-1.19[glamor]
```

helecho.

----------

## thican

 *helecho wrote:*   

> Thican, il s'agit explicitement de savoir si xorg-drivers est inclu dans l'arborescence des dépendances créée par Portage lors de la mise à jour.
> 
>  *thican wrote:*   Je pense que ça n’a pas fonctionné car il se peut effectivement que le paquet ne soit pas une dépendance [...]
> 
> Du coup, je pense qu’il est nécessaire de voir si un "depclean" ("emerge --ask --depclean") ne serait pas nécessaire pour nettoyer le système, et voir si Xorg restera. [...] 

 

Oui, c’est exactement ce que j’ai expliqué, un paquet ne sera pas dans l’arborescence des dépendances à cause de certaines conditions :

Un paquet peut ne pas être mis à jour si ce paquet en question n’est pas dans un ensemble (@world, @system, et autres dans le dossier "/etc/portage/sets/") ni une dépendance d’un autre, et aussi si ce paquet en question sert à construire d’autres paquets sans l’option --with-bdeps=y.

 *helecho wrote:*   

> D'après la Foire Aux Questions, Portage ne met pas à jour tous les paquets. Malheureusement, la réponse est évasive.

 

C’est dommage, tu fournis un lien, mais tu montres que tu n’as pas bien assimilé son contenu. Ça explique ce que je viens d’écrire dans ce message juste au dessus. Et d’où le fait que j’ai parlé de --depclean, pour justement retirer ceux qui n’ont plus de dépendances (bdeps ou pas).

Voici ce que j’utilise pour mettre à jour tous les paquets qui ne sont pas retirés avec --depclean :

```
emerge --verbose --ask --tree --update --newuse --deep --with-bdeps=y @world
```

En l’occurence, le paquet x11-base/xorg-server n’est pas un paquet dans un BDEPS, donc pas besoin de --with-bdeps=y pour lui.

Perso, j’ai utilisé le meta paquet x11-base/xorg-x11, mais je vois que des tas de paquets dépendent de x11-base/xorg-server à l’aide du USE flag "X" (pas nécessaire de le mettre en global, d’ailleurs, mais plus facile).

----------

## Mr. T.

 *thican wrote:*   

>  Oui, c’est exactement ce que j’ai expliqué, un paquet ne sera pas dans l’arborescence des dépendances à cause de certaines conditions : [...]

 

Tu l'as exprimé à ta manière mais sans être concis.

 *thican wrote:*   

> C’est dommage, tu fournis un lien, mais tu montres que tu n’as pas bien assimilé son contenu. Ça explique ce que je viens d’écrire dans ce message juste au dessus. 

 

 *helecho wrote:*   

> D'après la Foire Aux Questions, Portage ne met pas à jour tous les paquets. Malheureusement, la réponse est évasive. 

 

Je t'assure que j'ai suffisamment assimilé la FAQ, tu as dû mal comprendre mon propos. 

Mon avis est qu'on peut expliquer un objet complexe (comme Portage) de plusieurs façons sauf que certaines expositions sont ambiguës.

Les questions de la FAQ sont-elles liées d'une certaine manière (façon) ?

Les divers exemples d'une réponse sont-ils suffisant pour fournir une réponse complète ?

J'ai l'impression que les exemples d'une réponse ne représentent pas intégralement le propos. En conséquence, je pense que la réponse est évasive.

 *thican wrote:*   

>  Perso, j’ai utilisé le meta paquet x11-base/xorg-x11, mais je vois que des tas de paquets dépendent de x11-base/xorg-server à l’aide du USE flag "X"
> 
>  (pas nécessaire de le mettre en global, d’ailleurs, mais plus facile).

 

À mon avis, on ne progresse pas d'un iota car on ne sait pas comment Portage "calcule" les dépendances.

helecho.

----------

## Mr. T.

Je me suis fouvoyé à propos de l'activation globale de la USE flag X : elle était activé globalement (cf. emerge --info).

 *helecho wrote:*   

> À mon avis, l'origine du problème provenait de la USE flag X ; elle aurait due être activée globalement.

 

 *helecho wrote:*   

> À mon avis, on ne progresse pas d'un iota car on ne sait pas comment Portage "calcule" les dépendances.

 

Cela vous intéresse t'il ?

helecho.

----------

## xaviermiller

"on" sait très bien comment portage calcule les dépendances: https://wiki.gentoo.org/wiki/Package_Manager_Specification

Pour la partie concernant le use flag "X", je ne comprends pas la question. Pourrais-tu la refomuler ?

----------

## Mr. T.

Il s'agissait d'une affirmation erronée (constat tardif): "SebB n'avait pas activé la USE flag X globalement comme recommandée dans l'article". En fait, j'ai eu une confusion.

 *xaviermiller wrote:*   

> Pour la partie concernant le use flag "X", je ne comprends pas la question. Pourrais-tu la refomuler ?

 

 *xaviermiller wrote:*   

> "on" sait très bien comment portage calcule les dépendances: https://wiki.gentoo.org/wiki/Package_Manager_Specification 

 

Il s'agit d'une spécification réservée à des développeurs de gestionnaire de paquets fondés sur le concept d'ebuild. 

Peut-on présenter simplement, une mise à jour effectuée par le gestionnaire de paquets, par étapes sucessives ? 

cout <<< "Non, vous devez sûrement, connaître les principes de fonctionnement d'un gestionnaire de paquets, comprendre la spécification, 

analyser le code source  de Portage (partiellement documenté et potentiellement obscure)."

Il s'agit d'un propos reconstitué à partir de propos lus, peut-être un peu exagéré.

helecho.

----------

## El_Goretto

Une documentation officielle? Pfff, une solution de facilité pour les faibles. C'est triste. Bien trop maintream.

Alors qu'avec quelques hypothèses bien vagues et quelques arguties, on peut s'amuser comme des petits fous pendant ces longs moins d'hiver qui s'annoncent...

Z'êtes pas fun, les gens.

----------

## Mr. T.

La manière de procéder (faire des suppositions et des corrections rigoureuses) peut être inefficace.

 *El_Goretto wrote:*   

> (Avec) quelques hypothèses bien vagues et quelques arguties, on peut s'amuser comme des petits fous pendant ces longs moins d'hiver qui s'annoncent... 

 

 *El_Goretto wrote:*   

> Une documentation officielle ? [...]

 

Je n'ai pas trouvé d'informations utiles dans les manuels en ligne (man). 

D'ailleurs, j'ai l'impression que la documentation de Funtoo est vraiment pertinente contrairement à celle de Gentoo. 

Par exemple, on comprend immédiatement le rôle de l'option oneshot (emerge) en lisant deux phrases du manuel Funtoo alors qu'il m'a fallu 

beaucoup de temps pour la comprendre en lisant l'article Troubleshooting, les indications de la page de manuel emerge, en posant des questions, 

en réfléchissant ... (Portage n'arrivait pas à résoudre automatiquement des dépendances multiples : mise à jour de perl... !).

Autre exemple, l'affichage des caractères en mode console dans un environnement utilisant nativement l'encodage UTF-8 (e.g. avec la bibliothèque musl). 

Le fichier de configuration /etc/conf.d/consolefont est mentionné dès le début dans le manuel Funtoo ! 

Or, dans mon environnement (système), certains caractères ne s'affichaient pas correctement à cause de la fonte employée. 

Tandis que Gentoo présente brièvement l'encodage en mode console dans un article annexe du Wiki.

Dernier exemple, et non des moindres, concernant la documentation relative à Portage (le manuel du développeur).

 *devmanual wrote:*   

>  This document is an ongoing work in progress. It contains gaps, inaccuracies, omissions, typos and the occasional outright lie. The intent is to make a handbook giving developers and users correct, detailed, up to date technical content. 

 

En lisant le manuel, on croit que LINGUAS est une USE_EXPAND flag (voir les postes 8136260, 8136264 et 8136396). Aucun développeur ne semble s'en soucier suffisament.

On pourrait sûrement évoquer un grand nombre d'exemples (ou de cas) significatifs mais je ne souhaite pas polémiquer.

----------

