Re: suppression d'amarok + k3b sous testing (etch)
JusTiCe8 <justice8@wanadoo.fr> writes:
> Bonjour,
>
> Leopold BAILLY a écrit :
>
>>
>>L'intérêt de partir des sources est que les dépendances sont bien moins
>>fortes que sur le binaire. Je ne sais d'ailleurs pas pourquoi.
>>
>>Je me demande même si c'est réllement justifié ( contrainte de l'éditeur de
>>lien ? ) ou si c'est un effet de bord de l'outil de construction de paquet qui
>>ne sait pas faire mieux que "photographier" les librairies utilisées lors de
>>la compilation.
>>
>>Y aurait-il un DD dans la salle, pour éclairer ma lanterne ?
>>
>>
> je suis pas DD mais j'peux dire que la raison de ces dépendances et que
> lors de la construction d'un paquet binaire, on utilise fort logiquement
> les blibliothèques partagées de la version courante (libc6 d'unstable
> pour un paquet d'unstable par ex.) et la création de la liste des
> dépendances plus ou moins automatique par les outils de création de
> paquet associe donc la version liée au paquet construit.
C'est cette liste qui m'intéresse et le fait qu'elle soit générée.
> ex: paquet A compilé pour unstable avec libc6 d'unstable +
> lib_partagéeXYZ d'unstable
> le paquet A sous forme binaire dépend de ces 2 paquets, et l'installé
> tel quel sous stable/testing imposera d'installer libc6 +
> lib_partagéeXYZ dans leur version d'unstable.
>
> Parfois il s'agit de dépendances "faibles" car libc6 et lib_partagéeXYZ
> dans leur version unstable n'apporte que peu de changement (correctif
> d'un petit bug vicieux au fin fond d'un code peu utilisé, correctif dans
> le paquet lui-même comme une page man améliorée, l'adresse de la FSF
> mise à jour etc) et dans ce cas utiliser d'autres versions de ces
> blibliothèques partagées est facile (ne nécéssite pas de recompilation
> brute, en pratique une reconstruction du paquet est juste nécéssaire).
C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
> Dans le cas de dépendances "fortes" (interface d'une blibliothèques
> modifiée, par exemple A utilise une fonction de libc6 ou lib_partagéeXYZ
> appelée fonction F qui avait x paramètres avant et maintenant en à x+2
> ou x-1) là c'est plus génant et il sera nécéssaire de "backporter" la
> libc6/lib_partagéeXYZ d'unstable sur la version utilisée (cascade de
> dépendances en perspective) ce qui explique les erreurs que l'on
> rencontre parfois à la recompilation d'un paquet.
Oui, je me doute bien que les signatures ont changé ou s'il manque un symbole,
ça va poser problème à l'exécution.
> Voilà le pourquoi du comment des dépendances.
>
> En espérant avoir éclairer tes lanternes,
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
--
Léo.
Reply to: