Habituellement, je m'en sors tous seul pour les mise à jour de free (je
suis 4.9). Sauf que cette fois ci, pour la mise à jour de gnome2 (2.6).
Ca a foiré. Je me suis retrouvé avec pas mal d'appli qui n'était pas à
jour et qui ne voulait pas de gnome 2 2.6.
Je croyais que "portupgrade appliaupgrader" ca suffisait. Comment faire
pour que portupgrade, upgrade aussi les applis qui sont dépendante de
l'aplication que l'on upgrade. Waouh! Compliqué, non? J'aimerais éviter
la prochaine fois de faire un
# pkg_remove gnome2 && portinstall gnome2
Merci d'avance pour vos lumières
Portversion utilise une base de donnée qu'il faut mettre à jour avec portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot.
Non, non, non, *portsdb*. La différence entre pkg_version et portversion c'est que pkg_version utilise l'arbre des ports pour connaitre la version alors que portversion utilise une base de données.
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le lendemain pour voir le résultat, merci.
--
Michel TALON
Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
Philippe Chevalier écrivait :
Portversion utilise une base de donnée qu'il faut mettre à jour avec
portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot.
Non, non, non, *portsdb*. La différence entre pkg_version et portversion
c'est que pkg_version utilise l'arbre des ports pour connaitre la version
alors que portversion utilise une base de données.
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le
lendemain pour voir le résultat, merci.
Portversion utilise une base de donnée qu'il faut mettre à jour avec portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot.
Non, non, non, *portsdb*. La différence entre pkg_version et portversion c'est que pkg_version utilise l'arbre des ports pour connaitre la version alors que portversion utilise une base de données.
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le lendemain pour voir le résultat, merci.
--
Michel TALON
Ralph-
Philippe Chevalier wrote:
On Tue, 20 Apr 2004 18:13:26 +0200, Patrick Lamaizière wrote:
Portversion utilise une base de donnée qu'il faut mettre à jour avec portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et autres scories dans tous les coins. Autre gros defaut de "portupgrade" dans son ensemble a mon sens d'ailleurs, ou il faut constamment reparer la base de donnee qui devient rapidement incoherente avec tous les mouvements dans l'arbre des ports.
J'ai plus de 330 ports (je sais ca fait peur) et ma database est *nickel* En fait, j'install toujours en make install clean un port (en regardant quand meme si il n'y pas a des options sympa dans le makefile..) et ensuite un portupgrade -aR. Sur la machine concernée, j'ai meme pas souvenir d'avoir fait un pkgdb -F (faut dire, elle est partie d'une 4.9-RELEASE..). Par contre, une coupure de jus pendant portupgrade -aR apres un cvsup, bah ma db est un peu a la rue (genre il me manque pas mal de +CONTENTS dans les repertoires des ports installés..).
C'etait il y a quelques mois ceci dit et c'est un probleme qu'ils ont peut etre corrige.
J'ai commencé avec une 4.8 et ça marchait déjà comme ça.
Je ne suis pas convaincu qu'on parle de la meme chose.
K.
Philippe Chevalier wrote:
On Tue, 20 Apr 2004 18:13:26 +0200, Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
Portversion utilise une base de donnée qu'il faut mettre à jour avec
portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et
autres scories dans tous les coins. Autre gros defaut de "portupgrade"
dans son ensemble a mon sens d'ailleurs, ou il faut constamment
reparer la base de donnee qui devient rapidement incoherente avec
tous les mouvements dans l'arbre des ports.
J'ai plus de 330 ports (je sais ca fait peur) et ma database est *nickel*
En fait, j'install toujours en make install clean un port (en regardant
quand meme si il n'y pas a des options sympa dans le makefile..) et
ensuite un portupgrade -aR. Sur la machine concernée, j'ai meme pas souvenir
d'avoir fait un pkgdb -F (faut dire, elle est partie d'une 4.9-RELEASE..).
Par contre, une coupure de jus pendant portupgrade -aR apres un cvsup, bah
ma db est un peu a la rue (genre il me manque pas mal de +CONTENTS dans les
repertoires des ports installés..).
C'etait il y a quelques mois ceci dit et c'est un probleme qu'ils
ont peut etre corrige.
J'ai commencé avec une 4.8 et ça marchait déjà comme ça.
Je ne suis pas convaincu qu'on parle de la meme chose.
On Tue, 20 Apr 2004 18:13:26 +0200, Patrick Lamaizière wrote:
Portversion utilise une base de donnée qu'il faut mettre à jour avec portsdb après un cvsup des ports. Sinon, forcément ça marche pas.
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et autres scories dans tous les coins. Autre gros defaut de "portupgrade" dans son ensemble a mon sens d'ailleurs, ou il faut constamment reparer la base de donnee qui devient rapidement incoherente avec tous les mouvements dans l'arbre des ports.
J'ai plus de 330 ports (je sais ca fait peur) et ma database est *nickel* En fait, j'install toujours en make install clean un port (en regardant quand meme si il n'y pas a des options sympa dans le makefile..) et ensuite un portupgrade -aR. Sur la machine concernée, j'ai meme pas souvenir d'avoir fait un pkgdb -F (faut dire, elle est partie d'une 4.9-RELEASE..). Par contre, une coupure de jus pendant portupgrade -aR apres un cvsup, bah ma db est un peu a la rue (genre il me manque pas mal de +CONTENTS dans les repertoires des ports installés..).
C'etait il y a quelques mois ceci dit et c'est un probleme qu'ils ont peut etre corrige.
J'ai commencé avec une 4.8 et ça marchait déjà comme ça.
Je ne suis pas convaincu qu'on parle de la meme chose.
K.
Erwan David
(Xavier) écrivait :
Philippe Chevalier wrote:
Pour administrer mes ports, je fais regulierement un cvsup et je decide ce que je veux upgrader et j'upgrade dependance par dependance.
Sous NetBSD, on a un truc génial, qui s'appelle pkgdepgraph, et qui te donne ça :
Sous Free, il y a sysutils/pkg_tree, qui est moins joli, mais qui pouvait aussi servir à ça (jadis).
Tu n'as plus qu'à suivre le graphe pour faire "make replace" dans le bon ordre.
Il vaut tout de même éviter gnome... -- Th. Thomas.
Thierry Thomas
Mardi 20 avril 2004 à 18:05 GMT, Michel Talon a écrit :
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le lendemain pour voir le résultat, merci.
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été acceléré (à condition me semble-t-il d'avoir un arbre des ports complet, sans refuse, sinon ça ne finit pas...). -- Th. Thomas.
Mardi 20 avril 2004 à 18:05 GMT, Michel Talon a écrit :
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le
lendemain pour voir le résultat, merci.
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été
acceléré (à condition me semble-t-il d'avoir un arbre des ports complet,
sans refuse, sinon ça ne finit pas...).
--
Th. Thomas.
Mardi 20 avril 2004 à 18:05 GMT, Michel Talon a écrit :
Oui, et si tu as le malheur de faire tourner portsdb tu reviens le lendemain pour voir le résultat, merci.
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été acceléré (à condition me semble-t-il d'avoir un arbre des ports complet, sans refuse, sinon ça ne finit pas...). -- Th. Thomas.
espie
In article , Erwan David wrote:
Suivre à la maindoit quand même être complexe comme tout. Surtut quand c'est le port de gettext qui change...
Dans ce cas-la, c'est pas tres complexe, on enleve tout et on remet tout.
In article <8765buzesr.fsf@bretagne.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Suivre à la maindoit quand même être complexe comme tout. Surtut quand
c'est le port de gettext qui change...
Dans ce cas-la, c'est pas tres complexe, on enleve tout et on remet tout.
Suivre à la maindoit quand même être complexe comme tout. Surtut quand c'est le port de gettext qui change...
Dans ce cas-la, c'est pas tres complexe, on enleve tout et on remet tout.
Marwan Burelle
On 20 Apr 2004 16:54:09 GMT Philippe Chevalier wrote:
C'est du temps a prendre, mais je prefere le prendre et maitriser ce que j'installe.
C'est valable pour un serveur, mais sur une station de travail avec plein de truc et de gadget (je l'admet ... ) ça devient vite lourd ...
d'ailleurs au passage :
[ 12:08 ~]> pkg_info| wc -l 426
Ça commence à faire (et encore, à une époque j'en avais beaucoup plus d'installé)
Un autre, truc, je n'ai pas testé pkg_version depuis un petit moment, mais portversion (fournit avec portupgrade) était quand même plus rapide la dernière fois que j'ai fait la comparaison.
Un autre avantage de portupgrade, c'est l'upgrade binaire, pour pas mal de ports, la recompilation ne sert strictement à rien, à part perdre du temps, donc si la version package est dispo ... (au petit détail près que le script est assez pourri pour déterminer où aller chercher les packages, notamment si le uname contient RELEASE il va prendre dans packages-?-stable ce qui ne marche pas avec les releases 5.X)
Maintenant, je ne connais pas bien l'implentation de ruby, mais il me semble que sur certains points, les choses pourraient être mieux, notamment la gestion de la mémoire (garbage collecting ?) et certains problèmes de perfs. Bon, là encore, faudrait réécrire ça dans un langage plus efficace, un langage compilé tant qu'à faire, mais portupgrade existe, marche et est fortement pratique (portinstall, portsclean et la gestion des envirronnements de compilation spécifiques à chaque port sont quand même bien pratique.)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 20 Apr 2004 16:54:09 GMT
Philippe Chevalier <news@kyoko.org> wrote:
C'est du temps a prendre, mais je prefere le prendre et maitriser ce
que j'installe.
C'est valable pour un serveur, mais sur une station de travail avec
plein de truc et de gadget (je l'admet ... ) ça devient vite lourd ...
d'ailleurs au passage :
[feanor@pc5-179 12:08 ~]> pkg_info| wc -l
426
Ça commence à faire (et encore, à une époque j'en avais beaucoup plus
d'installé)
Un autre, truc, je n'ai pas testé pkg_version depuis un petit moment,
mais portversion (fournit avec portupgrade) était quand même plus rapide
la dernière fois que j'ai fait la comparaison.
Un autre avantage de portupgrade, c'est l'upgrade binaire, pour pas mal
de ports, la recompilation ne sert strictement à rien, à part perdre du
temps, donc si la version package est dispo ... (au petit détail près
que le script est assez pourri pour déterminer où aller chercher les
packages, notamment si le uname contient RELEASE il va prendre dans
packages-?-stable ce qui ne marche pas avec les releases 5.X)
Maintenant, je ne connais pas bien l'implentation de ruby, mais il me
semble que sur certains points, les choses pourraient être mieux,
notamment la gestion de la mémoire (garbage collecting ?) et certains
problèmes de perfs. Bon, là encore, faudrait réécrire ça dans un langage
plus efficace, un langage compilé tant qu'à faire, mais portupgrade
existe, marche et est fortement pratique (portinstall, portsclean et la
gestion des envirronnements de compilation spécifiques à chaque port
sont quand même bien pratique.)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On 20 Apr 2004 16:54:09 GMT Philippe Chevalier wrote:
C'est du temps a prendre, mais je prefere le prendre et maitriser ce que j'installe.
C'est valable pour un serveur, mais sur une station de travail avec plein de truc et de gadget (je l'admet ... ) ça devient vite lourd ...
d'ailleurs au passage :
[ 12:08 ~]> pkg_info| wc -l 426
Ça commence à faire (et encore, à une époque j'en avais beaucoup plus d'installé)
Un autre, truc, je n'ai pas testé pkg_version depuis un petit moment, mais portversion (fournit avec portupgrade) était quand même plus rapide la dernière fois que j'ai fait la comparaison.
Un autre avantage de portupgrade, c'est l'upgrade binaire, pour pas mal de ports, la recompilation ne sert strictement à rien, à part perdre du temps, donc si la version package est dispo ... (au petit détail près que le script est assez pourri pour déterminer où aller chercher les packages, notamment si le uname contient RELEASE il va prendre dans packages-?-stable ce qui ne marche pas avec les releases 5.X)
Maintenant, je ne connais pas bien l'implentation de ruby, mais il me semble que sur certains points, les choses pourraient être mieux, notamment la gestion de la mémoire (garbage collecting ?) et certains problèmes de perfs. Bon, là encore, faudrait réécrire ça dans un langage plus efficace, un langage compilé tant qu'à faire, mais portupgrade existe, marche et est fortement pratique (portinstall, portsclean et la gestion des envirronnements de compilation spécifiques à chaque port sont quand même bien pratique.)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Marwan Burelle
On 20 Apr 2004 16:45:45 GMT Philippe Chevalier wrote:
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et autres scories dans tous les coins. Autre gros defaut de "portupgrade" dans son ensemble a mon sens d'ailleurs, ou il faut constamment reparer la base de donnee qui devient rapidement incoherente avec tous les mouvements dans l'arbre des ports.
Non, c'est bien "portsdb -Uu" qu'il faut faire, de plus, pkg_version n'est pas forcément à jour si tu ne fait pas un make index (l'index des ports est toujours un peu décallé, et tu le vois si tu fais des upgrades régulières.)
Au passage, si je ne dis pas de bêtise, fut un temps où make index était suffisant, seulement portsdb -Uu était plus rapide, donc ... on est un peu au même point.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 20 Apr 2004 16:45:45 GMT
Philippe Chevalier <news@kyoko.org> wrote:
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et
autres scories dans tous les coins. Autre gros defaut de "portupgrade"
dans son ensemble a mon sens d'ailleurs, ou il faut constamment
reparer la base de donnee qui devient rapidement incoherente avec
tous les mouvements dans l'arbre des ports.
Non, c'est bien "portsdb -Uu" qu'il faut faire, de plus, pkg_version
n'est pas forcément à jour si tu ne fait pas un make index (l'index des
ports est toujours un peu décallé, et tu le vois si tu fais des upgrades
régulières.)
Au passage, si je ne dis pas de bêtise, fut un temps où make index était
suffisant, seulement portsdb -Uu était plus rapide, donc ... on est un
peu au même point.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On 20 Apr 2004 16:45:45 GMT Philippe Chevalier wrote:
Merci je sais. pkgdb -F plutot. Pour "fixer" les dependances et autres scories dans tous les coins. Autre gros defaut de "portupgrade" dans son ensemble a mon sens d'ailleurs, ou il faut constamment reparer la base de donnee qui devient rapidement incoherente avec tous les mouvements dans l'arbre des ports.
Non, c'est bien "portsdb -Uu" qu'il faut faire, de plus, pkg_version n'est pas forcément à jour si tu ne fait pas un make index (l'index des ports est toujours un peu décallé, et tu le vois si tu fais des upgrades régulières.)
Au passage, si je ne dis pas de bêtise, fut un temps où make index était suffisant, seulement portsdb -Uu était plus rapide, donc ... on est un peu au même point.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Olivier Tharan
* Thierry Thomas (Tue, 20 Apr 2004 20:09:30 +0000 (UTC)):
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été acceléré (à condition me semble-t-il d'avoir un arbre des ports complet, sans refuse, sinon ça ne finit pas...).
Oui, `make index' est relativement rapide maintenant, c'est la méthode recommandée (d'ailleurs portsdb a été modifié et fait un make index par-dessous). Et effectivement il y a tellement de dépendances entre les différentes branches qu'il faut tout avoir (ce qui représente 2,5 Go).
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été
acceléré (à condition me semble-t-il d'avoir un arbre des ports complet,
sans refuse, sinon ça ne finit pas...).
Oui, `make index' est relativement rapide maintenant, c'est la
méthode recommandée (d'ailleurs portsdb a été modifié et fait un
make index par-dessous). Et effectivement il y a tellement de
dépendances entre les différentes branches qu'il faut tout avoir
(ce qui représente 2,5 Go).
* Thierry Thomas (Tue, 20 Apr 2004 20:09:30 +0000 (UTC)):
Ça a été corrigé récemment, en utilisant le make index habituel, qui a été acceléré (à condition me semble-t-il d'avoir un arbre des ports complet, sans refuse, sinon ça ne finit pas...).
Oui, `make index' est relativement rapide maintenant, c'est la méthode recommandée (d'ailleurs portsdb a été modifié et fait un make index par-dessous). Et effectivement il y a tellement de dépendances entre les différentes branches qu'il faut tout avoir (ce qui représente 2,5 Go).
-- olive
Erwan David
Thierry Thomas écrivait :
Tu n'as plus qu'à suivre le graphe pour faire "make replace" dans le bon ordre.
Il vaut tout de même éviter gnome...
Le meilleur moyen est d'éviter de l'installer.
Comment j'ai marché dedans ?
-- Real programs don't eat cache
Thierry Thomas <tthomas@mail.dotcom.fr> écrivait :
Tu n'as plus qu'à suivre le graphe pour faire "make replace" dans le bon
ordre.
