Forum

Bonsoir tout le monde.
Ça fait un moment que je suis sous GNU/Linux maintenant, et je dois dire que je suis toujours aussi conquis. Mais je crois, il y a UNE chose qui m'a toujours rebuté.

Il arrive parfois, quelle que soit la distribution, alors que l'on cherche un logiciel un peu exotique, ou encore une version spécifique d'une application, il n'est pas rare de trouver des manques dans les dépôts logiciel.

Dans ce cas-là, sur les forums, souvent la même réponse « faut compiler ».
Mais voilà, même pour moi, qui travaille dans le domaine de l'informatique (même si actuellement je suis plus dans la branche des réseaux) j'ai toujours trouvé que la compilation sous GNU/Linux… bah, c'est la croix et la bannière. Il faut faire les bonnes commandes, il faut avoir les bonnes dépendances… Pour peu que l'on soit sur une distribution qui n'est pas « Debian Based » ou encore que l'application en question ne soit pas très clairement documentée… Bah, ça devient vite impossible ! En plus de ça, en cas de mis à jour, si on ne suit pas suffisamment les actus du logiciel, on ne sait pas quand le faire, et en plus, c'est reparti pour la compilation. Et encore, je ne parle même pas d'un utilisateur non expérimenté qui ramerait encore plus.

Je suis actuellement sous Manjaro. Je l'annonce clairement, je n'aime pas cette distribution : trop lente, trop instable, pas bien finie en comparaison à Mageia par exemple… mais bref tout ça n'est que mon avis. Le fait est, que dans cette distribution, il existe un outil : AUR. Cet outil est très intéressant, car celui-ci permet d'automatiser toutes les étapes de la compilation (dont le téléchargement des dépendances). Ce qui est donc très intéressant, et qui enlève un peu un épine du pied dans ce domaine-là.

Maintenant sous Mageia. Pouvons-nous trouver une équivalence? Y a-t-il seulement des moyens de simplifier la compilation ? Si ce n'est pas le cas, y a-t-il des projets là-dessus ? Ou bien, est-ce tout à fait farfelu d'imaginer voir ça un jour sur une distribution tel que Mageia ?

Merci d'avance pour vos réponses.

Édité par Comral Le 13/03/2017 à 01h37

Salut,

AUR c'est maintenu par la communauté. Si c'est jugé stable et sans soucis, c'est poussé dans les dépôts officiels "community".

Je crois que sous Mageia l'équivalent c'est le dépôt Backports

packages not present in the distribution (provided it doesn't obsolete or provide stuff that would impact the distribution, like backporting a new jvm with a obsolete on the current one)

Après compiler ce n'est pas compliqué, il y a souvent le fameux README avec les infos sur les dépendances à installer (là est l'avantage du gestionnaire de logiciels).

Et si faire des rpms t'interesse nous sommes là pour guider, aider, etc.

Il faut juste ne pas hésiter à poser ta question

Concernant les depots exterieurs moi, ca ne me derange pas du moment que les améliorations sont aussi remontée dans les repos mageia

neoclust tu m'intéresses. J'ouvre un nouveau post.

Bonjour, merci pour vos réponses.



Il est vrai que je n'ai pas regardé comment étaient les backports sous Mageia, je vais étudier le sujet dans un VM (comme ça je casserai pas mon système actuel ).

Après, pour la compilation, comme je disais un peu plus haut, oui quand c'est bien documenté, c'est pas bien compliqué. Mais j'ai déjà vu des applications où ce n'était pas forcément le cas. En plus de ça, les consignes pour les dépendances sont parfois données pour Debian, et pas forcément pour des distributions un peu plus humbles comme Mageia par exemple.



Je viens de regarder deux ou trois tutos sur la création des rpms, je dois admettre que je suis un petit peu perdu.
On parle bien des petits fichiers .rpm? Si c'est le cas, il fait quoi exactement? C'est un genre de script qui fait l'installation du programme en fait (en téléchargeant depuis les dépôts)? Je dois admettre que j'ai du mal à y voir clair (même si, en soi, ça ne semble pas très compliqué à faire).

Édité par Comral Le 13/03/2017 à 11h23

Comral:

que ce soit des dépendances pour debian, mageia ou tartempion, ça ne change rien à l'affaire, la plupart du temps, elles ne sont jamais spécifiques à une distrib et tu trouveras toujours le package qui va bien avec un nom adapté (et un numéro de version) adapté à la distrib. Par exemple sous debian la biblio de pulseaudio va se nommer libpulseaudio-dev et sous mageia lib64pulseaudio-devel. Au pire si le package n'existe vraiment pas, tu récupères les sources et c'est parti pour un tour, certes ça peut être laborieux, mais jamais impossible.

Non, mais je suis d'accord, c'est pas impossible (je pars du principe qu'en informatique et surtout sous GNU/Linux, quasiment rien n'est impossible). C'est seulement que, c'est quand même plus simple de faire un “yaourt nomDeTonPaquet” et qu'après il lance la compilation quand tu as choisi ton paquet dans aur. Plutôt que de commencer à chercher toutes les dépendances (dont la liste est parfois longue comme le bras) les installer en fonction des correspondances suivant la distri, après faire la petite compilation (qui dure parfois un petit moment quand même), tout ceci en espérant que le logiciel soit bien documenté (ce que, je rappelle, n'est pas toujours le cas)… Voilà.

Je dis pas que c'est impossible, mais c'est quand même compliqué. Je pense que l'utilisateur lambda sera vite découragé. Et pourtant, il pourrait en avoir besoin.

Édité par Comral Le 14/03/2017 à 09h12

Le but principal est qd meme que l'utilisateur lambda n'ait pas besoin de recompiler quoi que ce soit

neoclust:

En effet, dans le meilleur des mondes ou alors que la compilation se fasse de manière transparente pour l'utilisateur.

qui dit compilation dit installation de rpms -devel donc augmentation de la taille de l'install

Oui c'est sûr. J'ai pas trop vu comment les « devel » étaient gérés avec AUR, je vais essayer d'étudier un peu plus le sujet… Après, c'est vrai que la compilation ça prend du temps. Je l'ai vu avec une librairie qt en particulier, qui s'est compilée depuis AUR. Ben… Ça a pris le temps

Mais je suis sûr que penser un système pour pouvoir soit automatiser soit simplifier la compilation, pourrait permettre de gérer certains cas particuliers. Et ça ne pourrait être que bénéfique.

J'avoue ne pas très bien comprendre la discussion.

D'abord, on peut être appelé à compiler sous n'importe quel OS : Win, Mac, BSD, Solaris...

L'utilisateur lambda ne devrait jamais avoir à compiler, étant donné que toutes les applications utiles sont dans les dépôts, et que les applications non empaquetées dans les dépôts sont forcément plus exotiques.

Il n'y a donc rien d'extraordinaire qu'il faille compiler, et sous Nux tout est dans la console : dès qu'il manque une dépendance, une bibliothèque, c'est indiqué, où et comment.
Il n'y a qu'à suivre les indications, éventuellement se documenter, dès lors qu'il y a compilation, le paquet en question n'est pas optimisé pour la distribution, ce n'est pas un rpm, un deb, ou un txz, c'est à chaque fois un cas particulier, CQFD !

Je trouve au contraire remarquable la gestion de Linux, grâce notamment à la verbosité de la console et à la puissance de bash, la compilation trouve sa solution, à l'utilisateur de maîtriser son outil.

A t'écouté on en serait encore à voyager à cheval.

Merci pour la leçon, mais il faudrait commencer par comprendre ce que je dis.
La compilation n'est pas pour l'utilisateur lambda, et Mageia n'est pas responsable de toutes les applications à compiler.

Dès lors qu'on compile, il faut s'attendre à faire, éventuellement, quelques recherches de dépendances/biblios, et Mageia ne manque pas de backports, de tainted, qui m'ont aidé pendant des années dans des compilations même assez exotiques, et ce depuis Mandrake, en passant par Mandriva.

EDIT : Je n'ai pas plus de difficultés avec les compilations sous Mageia qu'avec Fedora ou Slackware.

Édité par paradise Le 19/04/2017 à 10h30

Bonjour,
L'alternative à la compilation va être disponible, de ce que j'ai compris, dans Mageia 6, à travers les dépôts COPR. Ce sont l'équivalent de des backports, mais fournis par des tiers, par exemple le fournisseur du logiciel.
Je n'en sais pas suffisamment pour en dire plus.