Pikachu_2014 wrote:Bonjour,

1) Le Requires sur python est superflu pour deux raisons :
- la première est que python-imaging est déjà déclaré en Requires et celui-ci dépend évidemment de python, d'où un Requires superflu.
- python est automatiquement détecté et ajouté en tant que Requires de toute façon au moment de la construction du RPM.

2) Petit détail également mais sans importance : il me semble que ta description ne dépasse pas les 80 caractères par lignes comme imposé par les Guidelines, mais j'ai l'impression que tu t'es même limité à 60 caractères ^^. Ça pourrait donner un affichage étriqué sur la console de yum ou même dans PackageKit ou yumex, je te suggère d'élargir un peu plus ton texte.
Ok je vais améliorer ça 🙂
Pikachu_2014 wrote:Là s'arrêtent les remarques adressées au packager ^^. Maintenant les remarques --- ou plutôt souhaits --- au développeur (puisque que tu sembles être le développeur de ce chouette programme).
L'utilisation de fakeroot était plus qu'approprié pour un script d'installation qui définit ses chemins en dur dans ton .spec. Cependant, à terme, peut-on espérer une option « --prefix » ou approchant, peu importe la forme, pour éviter le recours à fakeroot et customiser ses chemins d'installation ?
Bah quand j'ai commencé à faire le paquet debian, je me suis dis que ce serait bien pratique alors j'ai ajouté ça (option -p) seulement... j'ai oublié de permettre la copie des fichiers sans être root quand on utilise cette option (ce qui sera modifié dans la prochaine version) donc... ^^'
Pikachu_2014 wrote:As-tu d'ailleurs envisagé la possibilité d'utiliser les setuptools de Python ?
Bah heu non... c'est très bien à ce qu'il parait... mais faut que je me penche dessus 🙂

Merci pour tes remarques 😃
Vala j'ai modifié le spec 🙂
Parfait 🙂

Une dernière pour la route : juste un petit commentaire avant « fakeroot » pour expliquer le pourquoi de la commande, histoire de faciliter la tâche à celui qui en fera la revue.
Sinon ton paquet est, je pense, prêt à être soumis aux dépôts.
un an plus tard
À priori si la personne qui a ouvert le bug ne répond pas rapidement, Tiibs va fermé le bug.

Tu auras alors la possibilité de soumettre le tiens

N'hésite pas à nous faire relire tes specs ici, ça permet un premier regard sur ton travail (tu peux aussi donner le lien vers la revue bugzilla)
Actuellement j'ai pas trop le temps et mes mails s'empilent et j'ai pas eu le temps de répondre sur le tracker... Donc si tu veux prendre en charge le paquet rpm moi je suis pas contre ^^'

Si t'as besoin d'aide n'hésite pas par contre 🙂
Merci pour ces réponses rapides.

Je vais donc travailler su ce paquet. (principalement le lundi et le dimanche) donc pour les résultat, ce ne sera pas au jour le jour.

Je vous tiens au courant de la suite des évennements (je travaille dessus aujourd'hui).
Ferme alors toi même la revue sur le bugzilla, ça permettra à FLOZz de soumettre la sienne
Ce n'est pas à FLOZz de fermer la sienne pour que je crée la mienne?
Je vous présenterai mon paquet demain et ouvrirai ensuite un bug.

Bonne soirée.
Bonjour a tous.

Je vous présente mes travaux du jour (déjà bien aidé par l'excellent travail de FLOZz)

donc le fichier spec: cover-thumbnailer.spec

et le src.rpm: cover-thumbnailer-0.8.2-1.fc14.src.rpm

Voici les modifications effectuées:

- Retrait du mv des shemas dans le spec car plus besion dans cette version de cover-thumbnailer.

- Création d'un patch de l'installer car celui-ci copie la doc manuellement dans le répertoire /usr/share/doc/cover-thumbnailer/ en plus du spec qui le copie dans /usr/share/doc/cover-thumbnailer-0.8.2/

ce qui pose problème lors de la création de RPM.

Ce patch supprime simplement les lignes suivantes de l'installeur:
#/usr/share/doc/cover-thumbnailer
mkdir -pv "$1"/usr/share/doc/cover-thumbnailer 1>> $LOGFILE 2>> $LOGFILE || error=1
cp -v ./README "$1"/usr/share/doc/cover-thumbnailer 1>> $LOGFILE 2>> $LOGFILE || error=1
En espérant ne pas avoir oublié des choses.
À la limite plutôt que de patcher tu peux juste virer le dossier à la fin de l'%install

> mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/gconf/schemas/
Je ne pense pas qu'elle soit nécessaire cette ligne là

ton %changelog est pas correct, il doit refléter des modifications que tu as apporté au spec (ce que tu nous dit ici quoi)
Spec mis à jour.

Par contre, pour le patch.

La documentation précise de ne pas ajouter de ligne dans le spec mais bien de créer des patchs afin que ce soit plus clair pour les mainteneurs.

Ou est la limite pour créer des patchs?

(Et désolé d'avance pour mon anglais dans le changelog, je le travaille 😉 )
Dans la section files: 
%{_datadir}/applications/*
%{_datadir}/cover-thumbnailer/*
Je trouve ça moyen
il y a pas un rep cover-thumbnailer dans %{_datadir}/applications?
Bref je metterais plutôt: 
%{_datadir}/applications/cover-thumbnailer
%{_datadir}/cover-thumbnailer
Pour le patch c'est une question de taille de changement.

Si c'est juste changer une ligne je passe par sed, si c'est retirer des fichiers je les vire à la fin de la section %install, si c'est changé un gros bout de l'installeur pour qu'il fasse son boulot correctement, je patch.
En gros tout est faisable et le choix est laissé au mainteneur (ta solution ne bloquera pas la revue).

Ensuite quelque soit la solution choisie il faut en effet la documenter (les commentaires sont autorisé dans le spec) pour se rappeler de ce qui est fait.
Effectivement madko,

{_datadir}/applications/ ne contient que cover-thumbnailer-gui.desktop

Par contre {_datadir}/cover-thumbnailer/ contient 14 fichier.

Dois-je les mettres tous ou je met la solution que tu me propose.

EDIT: j'ai mis ta solution. J'apprend donc que pour un dossier contenant plusieurs fichiers il suffit de mettre le nom du dossier.

J'ai corrigé le spec afin que la section file ne contienne plus de lignes avec *

@pingou, merci de l'info. Je trouve que c'est plus clair avec le patch (point de vue personnel de nouveau empaqueteur 😉 ) Je vais laisser ainsi pour l'instant.

SPEC mis à jour.
@madko:

Dans /usr/share/applications/ tu n'as que un seul fichier : un .desktop utilisé pour générer les menus dans les environnements graphiques qui suivent les recommandations freedesktop. 🙂
donc il vaut mieux lister que ce fichier, pour éviter tout risque d'embarquer un fichier non voulu. Mais bon c'est du détail.