Forum

Reprise du message précédent

C'est bon, le paquet est construit et dans le dépôt MLO 8

Génial ! Merci !

Je viens de tester, tout marche parfaitement mais est-ce normal que les fichiers dat soit dans /usr/share et non dans /usr/share/littre ?

Bonjour,

Je dirais oui et non.

Réponse oui :

En fait le fichier .spec met les fichiers data dans /usr/share lors du %qmake_qt5 => Dans ce cas de figure on peut supposer que le comportement est normal.

Réponse non:

En principe il ne devrait pas y avoir de fichier isolés dans /usr/share . Peut être est ce une limitation technique ( chemin codé en dur quelque part dans le programme ) ?

Si Roland57 ou Papoteur passent par ici, ils devraient pouvoir faire la lumière là dessus.

edit: la variable DATALOCATION étant définie, dans le %qmake_qt5 on pourrait supposer qu' il s' agit d' une erreur de le fichier de spécifications.

Édité par nic80 Le 06/11/2022 à 15h20

Est-ce normal que je voie le paquet littre sur l'application ajouter/supprimer des programmes mais qu'il n'apparaît pas dans dnf ? Je suis nouveau à mageia et je ne comprends pas bien le système de paquet

Bonjour,

J' aurais tendance à dire que non. En principe dnf et rpmdrake sont des "frontends" pour la gestion des fichiers rpm installés ou installables sur le système. En revanche, chacun a sa manière des gérer les paquets (de ce que j' ai pu comprendre, la gestion des paquets orphelins (c' est dire installés sur le système mais qui n' ont "potentiellement" plus de raisons d' être là) est différente entre les deux (c' est d' ailleurs une des raisons d'éviter d' utiliser les deux en même temps, l' un n' ayant pas d' historique sur ce que l' autre a fait).

Ne connaissant pas dnf (et à fortiori dnfdragora, l' interface de gestion sous Mageia)). Je ne peux pas suggérer de commandes pour vérifier si dnf a connaissance du paquet littré installé).

Le dépôt MLO n'est disponible que pour urpmi. Malheureusement, nous n'avons pas le temps d'en faire un compatible dnf.

Ok pas de soucis, je pensais que l'application était uniquement un gui pour dnf donc cela fait plus de sens pour moi maintenant, merci de m'avoir expliqué. Je ferais le fichier dnf quand j'en aurais le temps

Le gestionnaire de logiciel est un frontend pour urpmi alors que dnfdragora est un frontend pour dnf.

Le problème est du côté serveur. Afin de découvrir et d'utiliser la liste des paquets disponibles sur le serveur, dnf et urpmi n'utilisent pas la même méthode. Or, le serveur MLO est configuré uniquement pour urpmi, dnf ne peut donc pas lire les données présentes sur celui-ci. Si tu sais comment configurer un dépôt dnf côté serveur pour qu'il soit lisible, tu peux te faire connaître sur le sujet dédié au dépôt MLO.

Ok merci de l'information, si un jour l'envie m'en prend je ferrais des recherches quant aux dépôts dnf

Normalement, rpmdrake affiche les paquets installés, quelle qu'en soit la provenance, référencés ou non dans un dépôt.
Je ne sais pas ce qu'il en est pour dnfdragora.
Par contre pour les paquets pas encore installés, les explications ont été données.

Je vais corriger la destination des fichiers .dat

Voilà, il y a une nouvelle version.

Merci Yves !

Prévoyez-vous de mettre une étiquette de version ?

J'ai supprimé le tag "2.1" dans l'intention de le recréer avec le même numéro, pour prendre en compte les dernières modifications. Hier soir j'ai complété le fichier README et j'attends le retour de mon coéquipier pour savoir s'il a d'autres modifications à proposer. Ensuite je recréerai le tag et la release. Probablement ce soir.

Ah, l'idée d'un tag est de présenter un photo unique à un moment donné.
Donc, ce n'est pas une bonne pratique de l'enlever pour le remettre et désigner autre chose.
Mets 2.1.1, 2.2 ou 3.0 si tu veux, mais pas la même étiquette. Considère là comme du consommable pas cher.
Sinon, ensuite, il y aura une ambigüité pour savoir si on parle de la 2.1 initiale ou de la 2.1 suivante.