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,
T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la
liste de s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté
non plus, pour ne pas enregistrer d'actions dans aptitude, tant que je
suis pas sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles?
(cad non utilisés par des paquets marqués "m")
Merci
A+
Reply to: