Re: suppression d'amarok + k3b sous testing (etch)
Leopold BAILLY a écrit :
> Thierry B <debian@thierry.eu.org> writes:
>
>
>>Leopold BAILLY a écrit :
>>
>>>Thierry B <debian@thierry.eu.org> writes:
>>>
>>>>Leopold BAILLY a écrit :
>>>>
>>>>>Thierry B <debian@thierry.eu.org> writes:
>
>
>>Dis moi, pa curiosié, est-ce qu'il y aurait une solution si on veut
>>installer un binaire d'unstable (si par exemple y'a des pbs dessus en
>>testing), sans casser les dépendances comme tu m'as montré, mais en
>>installant directement le binaire pq ca prend du temps de compiler...lol.
>
>
> Tu télécharge le .deb et tu tente un dpkg -i. Les chances que ça passe sont
> minimes, mais c'est possible.
>
> Tu peux y aller franco, soit ça s'intalle et c'est OK, soit dpkg t'envoie bouler
> en raison d'une dépendance non satisfaite.
>
>
>>Ta méthode à toi est pas mal, car apt-get build-dep à partir du source
>>unstable d'un paquet permet d'installer les paquets testing, qui
>>correspondent à la dépendance d'unstable, ce qui fait qu'en installant
>>que des paquets testing, (à part l'appli concerné unstable), on risque
>>pas de pb, donc j voulais savoir si on pouvait faire pareil pou
>>installer un binaire unstable au lieu d'une source unstable :-).
>
>
> 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 ?
>
>
>>>J'ai profité d'un récent fil pour me mettre à aptitude qui est plus puissant
>>>de ce côté là. Il distingue les paquets installés explicitement de ceux
>>>installés implicitement.
>>>
>>>Pour ça, il faut d'abord initialiser la base de données en se tapant tous les
>>>paquets un à un. On commence par tout marquer "automatique" (M) (on peut le
>>>faire sur une branche entière), puis on marque en "manuel" (m) les paquets de
>>>plus haut niveau que l'on souhaite garder.
>>
>>Si j'ai bien compris, Je vais sur chaque branche principale (j'ai tout ca
>>comme branches: "Paquets pouvant etre mise à jour", "Nouveau maquets",
>>"paquets installés", "paquets non installés", "paquets obsolètes ou crées
>>localement", "paquets virtuels" et "tache"), et pour chacune de ces branches,
>>je fais un marquage auto de paquet ? (je prefère demander avant de faire une
>>connerie lol)
>
>
> Oui, mais tu peux travailler sur des sous-branches, si tu hésites.
>
> Au départ, c'est impressionnant car aptitude veux tout virer, puis la liste se
> réduit au fur et à mesure des "m".
>
>
>>>Les paquets installés par apt-get sont considérés comme "automatique".
>>>
>>>Je vient d'ailleurs de le vérifier : aptitude puis g m'a permis de retirer
>>>les paquets -dev et des librairies utilisés lors de récentes compilations.
>>>
>>
>>Ha ok. Donc si des paquets sont installés avec apt, même si on utilis
>>aptitude, il ne fera juste que marquer ces paquets en auto.
>
>
> Disons que si tu installes des paquets avec apt-get, ils risquent de disparaître
> à la prochaine utilisation d'aptitude.
>
Re,
Désolé, j'avais oublié qque chose dnas ma précédente réponse.
Si on fait une install d'un paquet avec aptitude, est ce que apt
seraqu'il a ete installé et sera en mesure de le virer, et qu'aptitude
le sache?
Car si j'ai bien compris le seul problème serait l'install d'un paquet
sous apt, qu'il faudrait tout de sute marqué en "m" sur aptitude
après...mais si on inverse la situation aucun problème ne devrait se
poser non?
Merci :-)
A+
Reply to: