Je vais re-installer ma gate FreeBSD*, et je souhaiterais avoir quelques
conseils.
Tout d'abord, pour m'aider à découvrir Free, j'ai trouvé quelques
tutorials sur le net (dont celui de soup4you sur bsdvault).
- Lors d'une mise à jour du monde/kernel (make
buildworld/buildkernel/installworld/installkernel), est-ce que faire un
"mergemaster" est toujours util ou alors c'est "deprecated" ? Car sur
les tutorials que j'ai trouvé, il ne l'utilise pas alors que sur d'autre
oui (mais souvent des "vieux" tutorials).
- J'ai remarqué que par default, openssh se compile en meme temps que le
monde. Il est possible de ne pas le compiler en meme temps (via
make.conf, dite moi si je me trompe :)) ou alors via les ports. Je
suppose qu'il est mieux de prendre la version dans les ports pour eviter
à r'avoir à recompiler le monde lors de la decouverte d'un faille dans
openssh ? Que me conseiller vous ?
- Avez vous d'autre exemple de programme à eviter de compiler en meme
temps que le monde (je pense a sendmail) ?
Merci d'avance pour vos réponses, et toutes autres conseils sont les
bienvenus :)
(*): Je migre de Linux vers FreeBSD pour ma gate, et peut etre plus tard
ma workstation (pour de multiple raison). Je me fait donc les dents sur
Free ;)
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son build.sh, elle fasse au choix : - un arrêt d usystème. plus de bruit. - un mail - un bip strident. ton chien a déféqué dans la pièce, c'est donc que...
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18
heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la
gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son
build.sh, elle fasse au choix :
- un arrêt d usystème. plus de bruit.
- un mail
- un bip strident. ton chien a déféqué dans la pièce, c'est donc que...
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son build.sh, elle fasse au choix : - un arrêt d usystème. plus de bruit. - un mail - un bip strident. ton chien a déféqué dans la pièce, c'est donc que...
Stephane Dupille
Ça marche pas ça (enfin il me semble, j'ai eu des merdes avec ça une fois ou deux ...), le perl de la base est nécessaire à la base dans sa version, bon après c'est une véritable galère d'avoir les 2, mais bon vu que perl est nécessaire à gcc ...
Je n'ai pas recompilé le Perl du core depuis la 4.7, et je n'ai eu aucun soucis. Quand à avoir les deux, le script du port a prévu le coup, et fourni un petit utilitaire qui permet de jongler entre les deux versions.
Ne pas compiler un morceau du core ne signifie pas qu'il sera effacé. On garde simplement l'ancienne version.
-- Jh 28 ans, informaticien, cherche femme sur Chartres. -+- PGeorges in GNU - Elle est où la Charte du groupe ? -+-
Ça marche pas ça (enfin il me semble, j'ai eu des merdes avec ça une fois
ou deux ...), le perl de la base est nécessaire à la base dans sa version,
bon après c'est une véritable galère d'avoir les 2, mais bon vu que perl
est nécessaire à gcc ...
Je n'ai pas recompilé le Perl du core depuis la 4.7, et je n'ai eu
aucun soucis. Quand à avoir les deux, le script du port a prévu le
coup, et fourni un petit utilitaire qui permet de jongler entre les
deux versions.
Ne pas compiler un morceau du core ne signifie pas qu'il sera
effacé. On garde simplement l'ancienne version.
--
Jh 28 ans, informaticien, cherche femme sur Chartres.
-+- PGeorges in GNU - Elle est où la Charte du groupe ? -+-
Ça marche pas ça (enfin il me semble, j'ai eu des merdes avec ça une fois ou deux ...), le perl de la base est nécessaire à la base dans sa version, bon après c'est une véritable galère d'avoir les 2, mais bon vu que perl est nécessaire à gcc ...
Je n'ai pas recompilé le Perl du core depuis la 4.7, et je n'ai eu aucun soucis. Quand à avoir les deux, le script du port a prévu le coup, et fourni un petit utilitaire qui permet de jongler entre les deux versions.
Ne pas compiler un morceau du core ne signifie pas qu'il sera effacé. On garde simplement l'ancienne version.
-- Jh 28 ans, informaticien, cherche femme sur Chartres. -+- PGeorges in GNU - Elle est où la Charte du groupe ? -+-
Olivier Cherrier
In article <1g4htot.103p3whqaauyoN%, Xavier wrote:
Olivier Cherrier wrote:
Si le système met 4 jours ou 22 minutes à faire un build complet, ça influence pas mal le gain de l'opération. Non ?
Bien sûr.
Sur les gros serveurs du boulot, je peux lancer un make world à 17 heures, sans craindre d'y passer la nuit.
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
Problème connu aussi ... ;-) trop connu !
Enfin, pour un make build, y a pas besoin de rester devant et d'admirer toute la(es) nuit(s).
In article <1g4htot.103p3whqaauyoN%xavier@groumpf.org>, Xavier wrote:
Si le système met 4 jours ou 22 minutes à faire un build complet, ça
influence pas mal le gain de l'opération. Non ?
Bien sûr.
Sur les gros serveurs du boulot, je peux lancer un make world à 17
heures, sans craindre d'y passer la nuit.
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18
heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la
gueule si je suis encore devant mes xterm au lieu de me coucher :-)
Problème connu aussi ... ;-) trop connu !
Enfin, pour un make build, y a pas besoin de rester devant et d'admirer
toute la(es) nuit(s).
In article <1g4htot.103p3whqaauyoN%, Xavier wrote:
Olivier Cherrier wrote:
Si le système met 4 jours ou 22 minutes à faire un build complet, ça influence pas mal le gain de l'opération. Non ?
Bien sûr.
Sur les gros serveurs du boulot, je peux lancer un make world à 17 heures, sans craindre d'y passer la nuit.
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
Problème connu aussi ... ;-) trop connu !
Enfin, pour un make build, y a pas besoin de rester devant et d'admirer toute la(es) nuit(s).
Olivier Cherrier
In article , Miod Vallat wrote:
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son build.sh, elle fasse au choix : - un arrêt d usystème. plus de bruit.
Oui, pour autant que la matos permette le 'power off'.
- un mail
Pour le lire dans ton sommeil ?? ;-)
In article <slrnbrdi9a.bfj.miod@tekumel.gentiane.org>, Miod Vallat wrote:
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18
heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la
gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son
build.sh, elle fasse au choix :
- un arrêt d usystème. plus de bruit.
Oui, pour autant que la matos permette le 'power off'.
A la maison, si je peux gagner 1/2 heure sur une compil qui dure 18 heures, ça risque de tomber pile-poil à l'heure où ma femme me fera la gueule si je suis encore devant mes xterm au lieu de me coucher :-)
C'est de ta faute. Tu n'as qu'à configurer ta machine pour qu'après son build.sh, elle fasse au choix : - un arrêt d usystème. plus de bruit.
Oui, pour autant que la matos permette le 'power off'.
- un mail
Pour le lire dans ton sommeil ?? ;-)
Olivier Tharan
Olivier Cherrier writes:
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir un soft dans le système de base *ET* dans les ports. Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2 binaires sshd !
Le port openssh-portable dispose d'une option OPENSSH_OVERWRITE_BASE.
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir
un soft dans le système de base *ET* dans les ports.
Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2
binaires sshd !
Le port openssh-portable dispose d'une option OPENSSH_OVERWRITE_BASE.
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir un soft dans le système de base *ET* dans les ports. Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2 binaires sshd !
Le port openssh-portable dispose d'une option OPENSSH_OVERWRITE_BASE.
-- olive
espie
In article <bp53ga$vk2$, Olivier Cherrier wrote:
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir un soft dans le système de base *ET* dans les ports. Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2 binaires sshd !
Le seul interet, a mon sens, c'est que ca permet d'entretenir la confusion.
C'est comme tous ce systemes qui permettent d'installer plusieurs versions d'un soft en parallele... en fait, c'est vachement complique a faire tourner, et fort heureusement, ca sert assez peu.
En fait, c'est surtout la pour tous ces groupes qui n'ont pas de politique de gestion de version raisonnables, pour lesquels on ne sait pas trop quelle version installer, parce que la nouvelle est mieux, mais pas toujours.
Apache, gcc, autoconf, java, gnome.... la liste est longue.
Pour ma paroisse, en regardant un peu dans l'arbre des ports d'OpenBSD, nous avons effectivement quelques duplicata par rapport au systeme de base (binutils, gcc, fvwm2...), et quelques ports en double tout court (zsh, vim, ghostscript), voire en multiple exemplaire (autoconf, qt).
Dans chaque cas, ca aide `un peu' l'utilisateur tres experimente qui veut tester la derniere beta et s'amuser.
Et ca fout invariablement la merde pour l'utilisateur de base qui ne sait pas quelle version installer, ou qui se perd entre de multiples bugs de compatibilite dus a l'utilisation de la mauvaise version.
Enfin, je dis ca, mais les divers ports de qt cohabitent bien, ceux d'autoconf ne foutent la merde que pour les porters, parce qu'il n'y en a pas assez vu qu'il y a environ trois versions beta d'autoconf pour chaque version officiellement distribuee, et les divers ports de ghostscript sont la pour des histoires de licence.
Mais a la base, ca vient presqu'invariablement de gens qui n'arrivent pas a ecrire du soft sans tout reecrire de maniere incompatible, et sans tout recasser par derriere un jour.
Je ne m'etendrais meme pas sur les trucs qu'on n'a pas en plusieurs exemplaires, comme automake ou libtool, parce que ca a tellement foutu la merde a la base qu'on a laisse tomber avant meme de les integrer...
Anecdote non-bsd: le super systeme nunux a la mode, la, gentoo, eh bien ils proposent d'installer plusieurs versions de kde en parallele. J'ai vu ca a l'oeuvre, c'est pas beau a voir, parce qu'ils se sont vautre quelque part, et que donc kde 3.1.4 ne retrouve plus ses mimetypes la ou il faut.
En bref, plus c'est complique, moins c'est simple, et plus ca a des chances de pas marcher...
In article <bp53ga$vk2$3@news.brutele.be>,
Olivier Cherrier <Olivier.Cherrier@cediti.be> wrote:
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir
un soft dans le système de base *ET* dans les ports.
Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2
binaires sshd !
Le seul interet, a mon sens, c'est que ca permet d'entretenir la confusion.
C'est comme tous ce systemes qui permettent d'installer plusieurs versions
d'un soft en parallele... en fait, c'est vachement complique a faire
tourner, et fort heureusement, ca sert assez peu.
En fait, c'est surtout la pour tous ces groupes qui n'ont pas de politique
de gestion de version raisonnables, pour lesquels on ne sait pas trop
quelle version installer, parce que la nouvelle est mieux, mais pas
toujours.
Apache, gcc, autoconf, java, gnome.... la liste est longue.
Pour ma paroisse, en regardant un peu dans l'arbre des ports d'OpenBSD,
nous avons effectivement quelques duplicata par rapport au systeme de
base (binutils, gcc, fvwm2...), et quelques ports en double tout court
(zsh, vim, ghostscript), voire en multiple exemplaire (autoconf, qt).
Dans chaque cas, ca aide `un peu' l'utilisateur tres experimente qui veut
tester la derniere beta et s'amuser.
Et ca fout invariablement la merde pour l'utilisateur de base qui ne sait
pas quelle version installer, ou qui se perd entre de multiples bugs de
compatibilite dus a l'utilisation de la mauvaise version.
Enfin, je dis ca, mais les divers ports de qt cohabitent bien,
ceux d'autoconf ne foutent la merde que pour les porters, parce qu'il n'y
en a pas assez vu qu'il y a environ trois versions beta d'autoconf pour
chaque version officiellement distribuee, et les divers ports de
ghostscript sont la pour des histoires de licence.
Mais a la base, ca vient presqu'invariablement de gens qui n'arrivent pas
a ecrire du soft sans tout reecrire de maniere incompatible, et sans
tout recasser par derriere un jour.
Je ne m'etendrais meme pas sur les trucs qu'on n'a pas en plusieurs
exemplaires, comme automake ou libtool, parce que ca a tellement foutu la
merde a la base qu'on a laisse tomber avant meme de les integrer...
Anecdote non-bsd: le super systeme nunux a la mode, la, gentoo, eh bien
ils proposent d'installer plusieurs versions de kde en parallele. J'ai
vu ca a l'oeuvre, c'est pas beau a voir, parce qu'ils se sont vautre
quelque part, et que donc kde 3.1.4 ne retrouve plus ses mimetypes la ou
il faut.
En bref, plus c'est complique, moins c'est simple, et plus ca a des chances
de pas marcher...
J'avoue ne pas avoir vérifié sur FreeBSD mais ça paraît bizarre d'avoir un soft dans le système de base *ET* dans les ports. Les ports s'installent sous /usr/local/. Tu te retrouverais donc avec 2 binaires sshd !
Le seul interet, a mon sens, c'est que ca permet d'entretenir la confusion.
C'est comme tous ce systemes qui permettent d'installer plusieurs versions d'un soft en parallele... en fait, c'est vachement complique a faire tourner, et fort heureusement, ca sert assez peu.
En fait, c'est surtout la pour tous ces groupes qui n'ont pas de politique de gestion de version raisonnables, pour lesquels on ne sait pas trop quelle version installer, parce que la nouvelle est mieux, mais pas toujours.
Apache, gcc, autoconf, java, gnome.... la liste est longue.
Pour ma paroisse, en regardant un peu dans l'arbre des ports d'OpenBSD, nous avons effectivement quelques duplicata par rapport au systeme de base (binutils, gcc, fvwm2...), et quelques ports en double tout court (zsh, vim, ghostscript), voire en multiple exemplaire (autoconf, qt).
Dans chaque cas, ca aide `un peu' l'utilisateur tres experimente qui veut tester la derniere beta et s'amuser.
Et ca fout invariablement la merde pour l'utilisateur de base qui ne sait pas quelle version installer, ou qui se perd entre de multiples bugs de compatibilite dus a l'utilisation de la mauvaise version.
Enfin, je dis ca, mais les divers ports de qt cohabitent bien, ceux d'autoconf ne foutent la merde que pour les porters, parce qu'il n'y en a pas assez vu qu'il y a environ trois versions beta d'autoconf pour chaque version officiellement distribuee, et les divers ports de ghostscript sont la pour des histoires de licence.
Mais a la base, ca vient presqu'invariablement de gens qui n'arrivent pas a ecrire du soft sans tout reecrire de maniere incompatible, et sans tout recasser par derriere un jour.
Je ne m'etendrais meme pas sur les trucs qu'on n'a pas en plusieurs exemplaires, comme automake ou libtool, parce que ca a tellement foutu la merde a la base qu'on a laisse tomber avant meme de les integrer...
Anecdote non-bsd: le super systeme nunux a la mode, la, gentoo, eh bien ils proposent d'installer plusieurs versions de kde en parallele. J'ai vu ca a l'oeuvre, c'est pas beau a voir, parce qu'ils se sont vautre quelque part, et que donc kde 3.1.4 ne retrouve plus ses mimetypes la ou il faut.
En bref, plus c'est complique, moins c'est simple, et plus ca a des chances de pas marcher...
Marwan FeanoR/var Burelle
On Sun, 16 Nov 2003 00:58:02 +0100 Eric Masson wrote:
C'est effectivement le cas, les dépendances à perl pour la compilation du système ont été supprimées en -current
Là par contre je suis currieux, j'ai pas fait trop attention à ce qui se passait avec ma current (mais bon j'y touche pas trop, je suis très bien en stable) lors des recompiles, mais bon, ya plein de perl dans le make buildworld de stable, mais surtout, la dernière fois que j'ai compiler gcc à la main, il avait besoin de perl (il me semblait que c'était toujours le cas...)
On Sun, 16 Nov 2003 00:58:02 +0100
Eric Masson <emss@free.fr> wrote:
C'est effectivement le cas, les dépendances à perl pour la compilation
du système ont été supprimées en -current
Là par contre je suis currieux, j'ai pas fait trop attention à ce qui se
passait avec ma current (mais bon j'y touche pas trop, je suis très bien
en stable) lors des recompiles, mais bon, ya plein de perl dans le make
buildworld de stable, mais surtout, la dernière fois que j'ai compiler gcc
à la main, il avait besoin de perl (il me semblait que c'était toujours le
cas...)
On Sun, 16 Nov 2003 00:58:02 +0100 Eric Masson wrote:
C'est effectivement le cas, les dépendances à perl pour la compilation du système ont été supprimées en -current
Là par contre je suis currieux, j'ai pas fait trop attention à ce qui se passait avec ma current (mais bon j'y touche pas trop, je suis très bien en stable) lors des recompiles, mais bon, ya plein de perl dans le make buildworld de stable, mais surtout, la dernière fois que j'ai compiler gcc à la main, il avait besoin de perl (il me semblait que c'était toujours le cas...)
