Leopold BAILLY a écrit :Thierry B writes:
Rétro-porter le paquet de sid.
Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Rétro-porter le paquet de sid.
Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
Leopold BAILLY a écrit :Thierry B writes:
Rétro-porter le paquet de sid.
Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:
[...]Rétro-porter le paquet de sid.
[...]Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
OK, mais si tu prends l'habitude de rétro-porter les paquets, tu n'auras plus
besoin de la cible binaire de unstable.
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
$ dpkg-source -x amarok_1.3.5-1.dsc
Ceci va te créer l'arborescence. Ensuite :
$ cd amarok-1.3.5
$ dpkg-buildpackage -rfakeroot
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
À ma connaissance apt-get ne le permet pas.
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.
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.
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
[...]
Rétro-porter le paquet de sid.
[...]
Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
OK, mais si tu prends l'habitude de rétro-porter les paquets, tu n'auras plus
besoin de la cible binaire de unstable.
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
$ dpkg-source -x amarok_1.3.5-1.dsc
Ceci va te créer l'arborescence. Ensuite :
$ cd amarok-1.3.5
$ dpkg-buildpackage -rfakeroot
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
À ma connaissance apt-get ne le permet pas.
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.
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.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:
[...]Rétro-porter le paquet de sid.
[...]Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Ok.
Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:
J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500
# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990
OK, mais si tu prends l'habitude de rétro-porter les paquets, tu n'auras plus
besoin de la cible binaire de unstable.
Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src ftp://ftp2.fr.debian.org/debian/ unstable main contrib non-free
j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,
Est-ce que j'ai bien compris?
Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38618)
Et j'ai verifié, ca bugue à mort...
Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici (http://snapshot.debian.net/package/amarok).
J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...
$ dpkg-source -x amarok_1.3.5-1.dsc
Ceci va te créer l'arborescence. Ensuite :
$ cd amarok-1.3.5
$ dpkg-buildpackage -rfakeroot
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....
Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.
Comment je pourrais virer ces paquets là?
À ma connaissance apt-get ne le permet pas.
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.
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.
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
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 :-).
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)
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.
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.
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 :-).
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)
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.
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
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 :-).
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)
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.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
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.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
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.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B 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.
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?
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?
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?
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :
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.
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")
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
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.
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")
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :
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.
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")
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :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.
[...]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")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid : apt-get
build-dep m'a installé plein de paquets qui ont été automatiquement enlevés par
aptitude dist-upgrade.
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
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.
[...]
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")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid : apt-get
build-dep m'a installé plein de paquets qui ont été automatiquement enlevés par
aptitude dist-upgrade.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :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.
[...]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")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid : apt-get
build-dep m'a installé plein de paquets qui ont été automatiquement enlevés par
aptitude dist-upgrade.
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 ?
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 ?
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 ?
Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs dans
les paquets du fait, que la maj se fera dans plus de temps, non?
Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs dans
les paquets du fait, que la maj se fera dans plus de temps, non?
Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs dans
les paquets du fait, que la maj se fera dans plus de temps, non?
