Re: Package perso qui supprime /opt/ suite à un remove
Le 26/01/2014 21:06, Sylvain L. Sauvage a écrit :
> Le dimanche 26 janvier 2014 19:50:22 Francois Lafont a écrit :
>> […]
>>>> [… blabla répertoires vides blabla …]
>>
>> Oui désolé si ce n'est pas passionnant, je reconnais.
>> Mais j'espère qu'il n'y a pas de mépris quand même derrière
>> ce commentaire.
>
> Non, c’est juste une manière de résumer… un peu brutale
> parfois :o)
Ah ok, pas de souci. C'était un résumé très synthétique. :)
>
>> […]
>> Mais mon point de réflexion de départ, ce n'est pas
>> vraiment la distinction "paquet destiné à la distrib" vs
>> paquet « local », mais plutôt de savoir ce qui est
>> respectueux de la debian policy et ce qui ne l'est pas.
>
> Justement si : la Debian Policy s’occupe des paquets destinés
> à la distribution. Les règles sont donc édictées en conséquence.
> Quand tu fais un paquet local, tu peux contourner quelques
> règles. Si tu cherches à suivre toutes les règles, tu te
> retrouves à viser à faire un paquet intégrable tel quel (même si
> le but n’est pas de l’intégrer) et donc tu te retrouves plus
> restreint.
Ah ok. Alors c'est donc là où je n'étais pas au clair : donc
"paquet respectueux de la Debian policy" <=> "paquet potentiellement
destiné à la distrib". Et pour un paquet perso (local), on n'est
donc pas obligé de respecter à la lettre la Debian policy (même si
j'imagine que c'est toujours mieux d'essayer de se calquer au
mieux sur la politique qui fait autorité sur la distrib).
>> […]
>>> qu’un tarball).
>> Ok. Il me semble simplement que :
>>
>> - selon la politique Debian, un paquet
>
> _de la distribution_
>
>> peut créer des
>> répertoires vides /usr/local/*/machin à condition que
>> /usr/local/truc/ existe déjà ou fasse partie de la FHS.
>>
>> - et si le répertoire n'est pas vide ce n'est plus respectueux
>> de la Debian policy
>
> pour un paquet _de la distribution_.
>
>> .
>>
>> Je me trompe ?
>
> Oui, dans le sens où tu cherches à appliquer toutes les règles
> de la distribution pour un paquet qui n’a pas pour but d’être
> intégré à la distribution.
Ok. Je vois.
> Tu ne peux pas faire abstraction de
> la raison « pour être _distribuable_ » pour expliquer ou
> comprendre les règles d’une _distribution_ sous prétexte que tu
> ne veux pas distribuer.
>
> Analogie automobilesque : tu construis un kart pour jouer dans
> ton jardin en voulant suivre les règles des Mines pour un
> véhicule routier et tu veux décortiquer la règle qui régit la
> garde au sol minimale.
:-))
Ok, cette analogie, très parlante, m'a bien fait rire.
>
>> [… debhelper se plaint …]
>
> Parce que debhelper sert à faire simplement un paquet destiné
> à s’intégrer à la distribution.
Ok. Perso, si je me suis orienté vers les debhelper, c'est
parce qu'au départ, partant de zéro, je me suis tourné vers
de la doc en ligne et en général je préférais voir du côté
de sites Debian « officiels ». Et là je tombais presque
toujours sur debhelper il me semble. Enfin, il s'avère
que c'est pratique car debhelper fait plein de choses à
ma place (et sûrement mieux que je ne le ferais moi) comme par
exemple ajouter automatiquement des trucs dans les maintainer
scripts (entre autres choses).
> Tu veux faire un paquet Debian pour installer des trucs dans
> /usr/local (ou ailleurs) parce qu’un paquet est plus pratique
> qu’un simple tarball (gestion des dépendances, versionnage,
> reproductibilité, etc.).
> Il me semble évident qu’un paquet local a plus de marges de
> manœuvre qu’un paquet distribué, non ? Sinon, pourquoi y a-t-il
> des contournements possibles (et faciles) ?
Oui en effet.
Merci pour les explications.
--
François Lafont
Reply to: