Bonjour,
J'ai un serveur sous freebsd sans interface graphique et je souhaiterais
savoir quelle est la meilleure solution (la plus efficace) en vue de ne
plus synchroniser l'ensemble de ports.
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très
vite au cauchemard à gérer...
Merci d'avance
Gwenhaël
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ... +
Bonjour,
J'ai un serveur sous freebsd sans interface graphique et je souhaiterais
savoir quelle est la meilleure solution (la plus efficace) en vue de ne
plus synchroniser l'ensemble de ports.
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très
vite au cauchemard à gérer...
Merci d'avance
Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels
ports mettre a jour ...
+
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ... +
kavanier
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
Bonjour,
J'ai un serveur sous freebsd sans interface graphique et je souhaiterais
savoir quelle est la meilleure solution (la plus efficace) en vue de ne
plus synchroniser l'ensemble de ports.
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très
vite au cauchemard à gérer...
Merci d'avance
Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels
ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
gwenhael
Le Mon, 07 Jan 2008 09:29:30 +0100, kavanier a écrit :
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
Certes, mais le problème est que si je supprimer x11-* portsdb va me cracher dessus ... Je cherche une solution efficace pour d'une part ne plus avoir tous les ports que je ne veux pas mais aussi supprimer tous les ports qui en dépendent et que donc je ne veux pas... La solution de ports-supfile est bien mais ca deviens vite un enfer a cause des dépendances
Le Mon, 07 Jan 2008 09:29:30 +0100, kavanier a écrit :
Bonjour,
J'ai un serveur sous freebsd sans interface graphique et je souhaiterais
savoir quelle est la meilleure solution (la plus efficace) en vue de ne
plus synchroniser l'ensemble de ports.
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très
vite au cauchemard à gérer...
Merci d'avance
Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels
ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
Certes,
mais le problème est que si je supprimer x11-* portsdb va me cracher
dessus ...
Je cherche une solution efficace pour d'une part ne plus avoir tous les
ports que je ne veux pas mais aussi supprimer tous les ports qui en
dépendent et que donc je ne veux pas...
La solution de ports-supfile est bien mais ca deviens vite un enfer a
cause des dépendances
Le Mon, 07 Jan 2008 09:29:30 +0100, kavanier a écrit :
Bonjour, J'ai un serveur sous freebsd sans interface graphique et je souhaiterais savoir quelle est la meilleure solution (la plus efficace) en vue de ne plus synchroniser l'ensemble de ports. Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer. Je sais qu'il y a refuse pour faire ce genre de choses mais ça vire très vite au cauchemard à gérer... Merci d'avance Gwenhaël
Si tu fais la mise a jour avec cvsup, tu peux dire au systeme quels ports mettre a jour ...
oui un tres bon example dans /usr/share/examples/cvsup/ports-supfile
Certes, mais le problème est que si je supprimer x11-* portsdb va me cracher dessus ... Je cherche une solution efficace pour d'une part ne plus avoir tous les ports que je ne veux pas mais aussi supprimer tous les ports qui en dépendent et que donc je ne veux pas... La solution de ports-supfile est bien mais ca deviens vite un enfer a cause des dépendances
Eric Masson
gwenhael writes:
'Lut,
La solution de ports-supfile est bien mais ca deviens vite un enfer a cause des dépendances
Malheureusement, il n'y a pas vraiment d'autres solutions...
Ou alors, ne pas installer les ports, rester dans une release, utiliser les mécanismes de mise à jour binaire (freebsd-update) et utiliser les packages pour l'installation de softs tiers.
-- AP disait à Grand Neuneu : blagues GNU en signature... Le contraire m'aurait étonné. -+- AP in <http://www.le-gnu.net> : Le neuneu par l'exemple -+-
gwenhael <gwenjo@free.fr> writes:
'Lut,
La solution de ports-supfile est bien mais ca deviens vite un enfer a
cause des dépendances
Malheureusement, il n'y a pas vraiment d'autres solutions...
Ou alors, ne pas installer les ports, rester dans une release, utiliser
les mécanismes de mise à jour binaire (freebsd-update) et utiliser les
packages pour l'installation de softs tiers.
--
AP disait à Grand Neuneu :
blagues GNU en signature...
Le contraire m'aurait étonné.
-+- AP in <http://www.le-gnu.net> : Le neuneu par l'exemple -+-
La solution de ports-supfile est bien mais ca deviens vite un enfer a cause des dépendances
Malheureusement, il n'y a pas vraiment d'autres solutions...
Ou alors, ne pas installer les ports, rester dans une release, utiliser les mécanismes de mise à jour binaire (freebsd-update) et utiliser les packages pour l'installation de softs tiers.
-- AP disait à Grand Neuneu : blagues GNU en signature... Le contraire m'aurait étonné. -+- AP in <http://www.le-gnu.net> : Le neuneu par l'exemple -+-
gwenhael
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et hop. Non ? Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et
hop. Non ?
Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le
refasse à la main ...
Et puis je n'ai pas envie de subir des tartines de libs & co dont je me
fiche...
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et hop. Non ? Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
espie
In article , gwenhael wrote:
Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
Je comprend pas trop, voire pas du tout cette attitude. Si c'etait un GROS et enorme machin, je comprendrais, mais l'arbre des ports, c'est quand meme pas monstrueux en terme de taille...
Si cvsup deconne, il y a d'autres options, cvsync a tendance a mieux marcher (et a etre nettement plus portable pour des raisons evidentes).
Mais pour le reste, l'idee d'elaguer l'arbre des ports, ca me parait une occupation pas du tout vitale de quelqu'un qui a du temps a perdre...
In article <pan.2008.01.07.12.19.44.870486@free.fr>,
gwenhael <gwenjo@free.fr> wrote:
Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le
refasse à la main ...
Et puis je n'ai pas envie de subir des tartines de libs & co dont je me
fiche...
Je comprend pas trop, voire pas du tout cette attitude. Si c'etait un GROS
et enorme machin, je comprendrais, mais l'arbre des ports, c'est quand meme
pas monstrueux en terme de taille...
Si cvsup deconne, il y a d'autres options, cvsync a tendance a mieux marcher
(et a etre nettement plus portable pour des raisons evidentes).
Mais pour le reste, l'idee d'elaguer l'arbre des ports, ca me parait une
occupation pas du tout vitale de quelqu'un qui a du temps a perdre...
Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
Je comprend pas trop, voire pas du tout cette attitude. Si c'etait un GROS et enorme machin, je comprendrais, mais l'arbre des ports, c'est quand meme pas monstrueux en terme de taille...
Si cvsup deconne, il y a d'autres options, cvsync a tendance a mieux marcher (et a etre nettement plus portable pour des raisons evidentes).
Mais pour le reste, l'idee d'elaguer l'arbre des ports, ca me parait une occupation pas du tout vitale de quelqu'un qui a du temps a perdre...
Paul Gaborit
À (at) Mon, 07 Jan 2008 13:19:45 +0100, gwenhael écrivait (wrote):
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et hop. Non ? Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
Pour les performances, il suffit d'adopter 'portsnap' en remplacement de 'cvsup'.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ 1/2Go. De nos jours, ce n'est vraiment pas grand chose...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 07 Jan 2008 13:19:45 +0100,
gwenhael <gwenjo@free.fr> écrivait (wrote):
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de
morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et
hop. Non ?
Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le
refasse à la main ...
Et puis je n'ai pas envie de subir des tartines de libs & co dont je me
fiche...
Pour les performances, il suffit d'adopter 'portsnap' en remplacement
de 'cvsup'.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ
1/2Go. De nos jours, ce n'est vraiment pas grand chose...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 07 Jan 2008 13:19:45 +0100, gwenhael écrivait (wrote):
Le Mon, 07 Jan 2008 12:51:38 +0100, Patrick Lamaizière a écrit :
gwenhael wrote:
Ca m'énerve un peu de voir lors d'une synchro des tonnes de jeux ou de morceaux de l'interface graphique (xorg, kde, gtk,...) passer.
Ben on est pas obligé de regarder benoitement, un coup de cron la nuit et hop. Non ? Certes mais ça arrive que cvsup se fasse déconnecter, trois fois sur
quatre j'ai droit à un core dump, résultat cron ou pas faut que je me le refasse à la main ... Et puis je n'ai pas envie de subir des tartines de libs & co dont je me fiche...
Pour les performances, il suffit d'adopter 'portsnap' en remplacement de 'cvsup'.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ 1/2Go. De nos jours, ce n'est vraiment pas grand chose...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Mon, 07 Jan 2008 19:15:21 +0100, Patrick Lamaizière écrivait (wrote):
Paul Gaborit wrote:
Pour les performances, il suffit d'adopter 'portsnap' en remplacement de 'cvsup'.
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière très efficace.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ 1/2Go. De nos jours, ce n'est vraiment pas grand chose...
420 Mo... Et pleins d'inodes, je suis déjà tombé à cours d'inode par le passé.
Si vous tenez absolument à filtrer, il y a toujours la possibilité d'utiliser la directive REFUSE dans portsnap.conf (elle permet de réglages fins sur les ports à mettre à jour ou non mais je ne l'ai jamais utilisée). Sans oublier tout de même que :
Note that operating with an incomplete ports tree is not supported and may cause unexpected results.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 07 Jan 2008 19:15:21 +0100,
Patrick Lamaizière <patnews1@davenulle.org> écrivait (wrote):
Paul Gaborit wrote:
Pour les performances, il suffit d'adopter 'portsnap' en remplacement
de 'cvsup'.
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de
méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière
très efficace.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ
1/2Go. De nos jours, ce n'est vraiment pas grand chose...
420 Mo... Et pleins d'inodes, je suis déjà tombé à cours d'inode par le
passé.
Si vous tenez absolument à filtrer, il y a toujours la possibilité
d'utiliser la directive REFUSE dans portsnap.conf (elle permet de
réglages fins sur les ports à mettre à jour ou non mais je ne l'ai
jamais utilisée). Sans oublier tout de même que :
Note that operating with an incomplete ports tree is not supported
and may cause unexpected results.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 07 Jan 2008 19:15:21 +0100, Patrick Lamaizière écrivait (wrote):
Paul Gaborit wrote:
Pour les performances, il suffit d'adopter 'portsnap' en remplacement de 'cvsup'.
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière très efficace.
Pourquoi vouloir filtrer ? L'ensemble des ports doit occuper environ 1/2Go. De nos jours, ce n'est vraiment pas grand chose...
420 Mo... Et pleins d'inodes, je suis déjà tombé à cours d'inode par le passé.
Si vous tenez absolument à filtrer, il y a toujours la possibilité d'utiliser la directive REFUSE dans portsnap.conf (elle permet de réglages fins sur les ports à mettre à jour ou non mais je ne l'ai jamais utilisée). Sans oublier tout de même que :
Note that operating with an incomplete ports tree is not supported and may cause unexpected results.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Tue, 8 Jan 2008 10:11:21 +0000 (UTC), Patrick Lamaizière écrivait (wrote):
Paul Gaborit écrivait
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière très efficace.
Il fait quoi exactement ? Je pense qu'il ne recopie que l'index fetché.
Oui. Mais cet index est exactement à jour par rapport à l'arborescence récupérée par portsnap, contrairement aux index récupérés par cvsup.
À moins de jouer sur l'option '-l descfile' et de faire un make describe dans les ports installés ?
Pourquoi faire ? Tu modifies directement les makefile des ports ? Dans ce cas, je ne suis pas sûr que portsnap ou cvsup soient des outils adaptés... Ou alors, tu as des ports locaux et dans ce cas, l'option '-l' est exactement faite pour ça.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 8 Jan 2008 10:11:21 +0000 (UTC),
Patrick Lamaizière <adresse@est.invalid> écrivait (wrote):
Paul Gaborit écrivait
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de
méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière
très efficace.
Il fait quoi exactement ? Je pense qu'il ne recopie que l'index fetché.
Oui. Mais cet index est exactement à jour par rapport à l'arborescence
récupérée par portsnap, contrairement aux index récupérés par cvsup.
À moins de jouer sur l'option '-l descfile' et de faire un make
describe dans les ports installés ?
Pourquoi faire ? Tu modifies directement les makefile des ports ? Dans
ce cas, je ne suis pas sûr que portsnap ou cvsup soient des outils
adaptés... Ou alors, tu as des ports locaux et dans ce cas, l'option
'-l' est exactement faite pour ça.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 8 Jan 2008 10:11:21 +0000 (UTC), Patrick Lamaizière écrivait (wrote):
Paul Gaborit écrivait
Ce qui est long c'est de reconstruire l'index, je n'ai pas trouvé de méthodes vraiment intéressantes pour ça.
'portsnap' se charge aussi de (re)construire l'index... et de manière très efficace.
Il fait quoi exactement ? Je pense qu'il ne recopie que l'index fetché.
Oui. Mais cet index est exactement à jour par rapport à l'arborescence récupérée par portsnap, contrairement aux index récupérés par cvsup.
À moins de jouer sur l'option '-l descfile' et de faire un make describe dans les ports installés ?
Pourquoi faire ? Tu modifies directement les makefile des ports ? Dans ce cas, je ne suis pas sûr que portsnap ou cvsup soient des outils adaptés... Ou alors, tu as des ports locaux et dans ce cas, l'option '-l' est exactement faite pour ça.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Ollivier Robert
Dans l'article , Paul Gaborit <Paul.Gaborit+ disait :
'portsnap' se charge aussi de (re)construire l'index... et de manière très efficace.
Ne pas oublier non plus le classique « cd /usr/ports && make fetchindex && portsdb -u »
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <wt9d4scwwby.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit+news@enstimac.fr> disait :
'portsnap' se charge aussi de (re)construire l'index... et de manière
très efficace.
Ne pas oublier non plus le classique
« cd /usr/ports && make fetchindex && portsdb -u »
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
