m'étant mis à FreeBSD depuis environ un mois, j'ai passé pas mal de
temps à lire de la doc après avoir installé la release 6.2. Il subsiste
des questions sans réponses. Je les livre en l'état, en essayant
d'éliminer les grosses anneries...
1 ) Pour mettre a jour les sources du système on mentionne souvent
cvsup, qu'en est-il de freebsd-update? A-t'il le même rôle que cvsup ?
Doit-on l'utiliser régulièrement comme portupgrade ?
2 ) N'ayant jamais utilisé cvsup, je n'ai fait qu'utiliser portupgrade
et je devine que mon système ne peut se voir apposer aucune des
étiquettes CVS connues (releng,current/stable). Y'a-t-il une
dénomination/catégorie pour ce système ? Est-il exacte de dire que je
suis toujours en 6.2_RELEASE (c'est enfait la sortie de uname -r)?
3 ) Mettons que je mette à jour mes sources avec cvsup, comment le
système fait-il pour déterminer les ports que je pourrai mettre à jour
par la suite ? Enfait est ce que le choix d'une étiquette influence la
disponibilité de tel ou tel logiciel porté ?
4 ) Quelle différence y-a-t-il entre portupgrade -a et portupgrade
-ar(R) ? Pour un port donné, ses dépendances se verront également mis à
jour recursivement, puisqu'elles sont à priori listées quand je
'pkg_version -vl "<"'
5 ) Parfois, en éditant une commande (pas nécessairement très longue)
sous xterm(que je sois en plein écran ou, par défaut, en 80*24), le
retour chariot ne se fait pas naturellement (comme s'il y avait une
frontière invisible) et la commande empiète par la suite sur mon prompt
(à la même ligne) si bien qu'à la fin, je vois plus ce que j'ai tapé. Je
dois alors fermer le xterm et en ouvrir un autre.
Merci d'avance pour toute ébauche de réponse/solution.
m'étant mis à FreeBSD depuis environ un mois, j'ai passé pas mal de temps à lire de la doc après avoir installé la release 6.2. Il subsiste des questions sans réponses. Je les livre en l'état, en essayant d'éliminer les grosses anneries...
Félicitations ! Tant pour le choix que pour la méthode de travail ;)
1 ) Pour mettre a jour les sources du système on mentionne souvent cvsup, qu'en est-il de freebsd-update? A-t'il le même rôle que cvsup ? Doit-on l'utiliser régulièrement comme portupgrade ?
2 ) N'ayant jamais utilisé cvsup, je n'ai fait qu'utiliser portupgrade et je devine que mon système ne peut se voir apposer aucune des étiquettes CVS connues (releng,current/stable). Y'a-t-il une dénomination/catégorie pour ce système ? Est-il exacte de dire que je suis toujours en 6.2_RELEASE (c'est enfait la sortie de uname -r)?
3 ) Mettons que je mette à jour mes sources avec cvsup, comment le système fait-il pour déterminer les ports que je pourrai mettre à jour par la suite ? Enfait est ce que le choix d'une étiquette influence la disponibilité de tel ou tel logiciel porté ?
Bon, je vais faire une réponse "générique" sur la mise à jour.
Dans FreeBSD (et dans Net et Open également) il y a une séparation "forte" entre le système (le minimum nécessaire ou presque) que l'on appelle la base et les "applications tiers" (les ports/pkg.)
Outre les binaires et bibliothèque de la base, on retrouve la base sous forme de sources dans /usr/src. Ces sources peuvent être utilisées pour compiler un noyeau spécifique ou mettre à jour le système (la base donc.)
Pour mettre à jour le système, on commence par mettre à jour les sources, en général avec cvsup. Une fois ces sources à jour (ou en tout cas à jour par rapport à une versio, ou un tag donné) on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente et globalement sûre (si on est sûre de sa machine et de la version récupérée.) Je vous conseille de lire la doc sur le sujet avant de vous lancer dedans, mais une fois que l'on l'a fait une fois, on se rend compte que ce n'est pas bien compliqué (moins que ce que la verbosité de la doc pourrait laisser croire.)
Il existe d'autre méthode pour mettre à jour la base, donc notamment freebsd-update qui utilise une mise à jour binaire. Mais pour qu'une mise à jour binaire soit possible il faut que ces binaires existent. Je n'ai jamais creusé la question freebsd-update, mais je suppose qu'il n'est pas vraiment possible de suivre STABLE ou CURRENT avec ça ... Par contre, je suppose que cela permet de se mettre à jour rapidement (la recompile du monde, c'est long.)
Pour les ports, les choses sont à la fois similaires et différentes. Les ports (et les pkg) "existent" sur un système installé de 2 façon: les applications installées sont répertoriées dans /var/db/pkg et l'ensemble des applications disponibles sont listées dans /usr/ports
La "liste" dans ports correspond à l'état des ports à un instant donné. Pour mettre à jour les applications installées, il faut mettre à jour cette liste. On passe encore par cvsup. Après par contre, il y a plusieures solutions pour mettre à jour un ou plusieures ports.
Il y a les solutions "à la main" desinstalle/reinstalle. La solution à peine mieux de pkg_version (mais je crois que l'option qui engendrait un script de mise à jour tout fait a été suprimé.) Et les solutions comme portupgrade, qui finalement font à peine plus, mais ce à peine fait toute la différence (trie en fonction de dépendances, sauvegardes ... )
On peut aussi mettre à jour les ports via binaire (portupgrade -P par exemple), mais comme pour la base, il faut que ces binaires soient disponibles.
Enfin, on notera que l'évolution des ports est totalement indépendante de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
4 ) Quelle différence y-a-t-il entre portupgrade -a et portupgrade -ar(R) ? Pour un port donné, ses dépendances se verront également mis à jour recursivement, puisqu'elles sont à priori listées quand je 'pkg_version -vl "<"'
Il existe parfois des cas un peu compliqué de mise à jour où un port est "à jour" (il n'est pas listé par pkg_version ou portversion) mais doit être recompilé pour correspondre à un autre port qui lui a été (ou va être) mis à jour.
Je ne sais pas si portupgrade gère tout seul (dans tous les cas) ce genre de chose maintenant, le plus sûr est de coller le "-r" systématiquement au lorsque l'on fait un portupgrade "-a". Le "-R" peut aussi être nécessaire ou utile s'il y a une nouvelle dépendance et que l'on utilise l'option "-P".
5 ) Parfois, en éditant une commande (pas nécessairement très longue) sous xterm(que je sois en plein écran ou, par défaut, en 80*24), le retour chariot ne se fait pas naturellement (comme s'il y avait une frontière invisible) et la commande empiète par la suite sur mon prompt (à la même ligne) si bien qu'à la fin, je vois plus ce que j'ai tapé. Je dois alors fermer le xterm et en ouvrir un autre.
Je n'utilise plus xterm depuis longtemps ... rxvt se comporte "mieux" pour moi ;)
-- Marwan Burelle.
In article <4652f59a$0$3216$426a74cc@news.free.fr>, Lie Algebra wrote:
Bonjour,
m'étant mis à FreeBSD depuis environ un mois, j'ai passé pas mal de
temps à lire de la doc après avoir installé la release 6.2. Il subsiste
des questions sans réponses. Je les livre en l'état, en essayant
d'éliminer les grosses anneries...
Félicitations ! Tant pour le choix que pour la méthode de travail ;)
1 ) Pour mettre a jour les sources du système on mentionne souvent
cvsup, qu'en est-il de freebsd-update? A-t'il le même rôle que cvsup ?
Doit-on l'utiliser régulièrement comme portupgrade ?
2 ) N'ayant jamais utilisé cvsup, je n'ai fait qu'utiliser portupgrade
et je devine que mon système ne peut se voir apposer aucune des
étiquettes CVS connues (releng,current/stable). Y'a-t-il une
dénomination/catégorie pour ce système ? Est-il exacte de dire que je
suis toujours en 6.2_RELEASE (c'est enfait la sortie de uname -r)?
3 ) Mettons que je mette à jour mes sources avec cvsup, comment le
système fait-il pour déterminer les ports que je pourrai mettre à jour
par la suite ? Enfait est ce que le choix d'une étiquette influence la
disponibilité de tel ou tel logiciel porté ?
Bon, je vais faire une réponse "générique" sur la mise à jour.
Dans FreeBSD (et dans Net et Open également) il y a une séparation
"forte" entre le système (le minimum nécessaire ou presque) que l'on
appelle la base et les "applications tiers" (les ports/pkg.)
Outre les binaires et bibliothèque de la base, on retrouve la base
sous forme de sources dans /usr/src. Ces sources peuvent être
utilisées pour compiler un noyeau spécifique ou mettre à jour le
système (la base donc.)
Pour mettre à jour le système, on commence par mettre à jour les
sources, en général avec cvsup. Une fois ces sources à jour (ou en
tout cas à jour par rapport à une versio, ou un tag donné) on peut
reconstruire (globalement on recompile) "le monde". Cette phase est
lente et globalement sûre (si on est sûre de sa machine et de la
version récupérée.) Je vous conseille de lire la doc sur le sujet
avant de vous lancer dedans, mais une fois que l'on l'a fait une fois,
on se rend compte que ce n'est pas bien compliqué (moins que ce que la
verbosité de la doc pourrait laisser croire.)
Il existe d'autre méthode pour mettre à jour la base, donc notamment
freebsd-update qui utilise une mise à jour binaire. Mais pour qu'une
mise à jour binaire soit possible il faut que ces binaires
existent. Je n'ai jamais creusé la question freebsd-update, mais je
suppose qu'il n'est pas vraiment possible de suivre STABLE ou CURRENT
avec ça ... Par contre, je suppose que cela permet de se mettre à jour
rapidement (la recompile du monde, c'est long.)
Pour les ports, les choses sont à la fois similaires et
différentes. Les ports (et les pkg) "existent" sur un système installé
de 2 façon: les applications installées sont répertoriées dans
/var/db/pkg et l'ensemble des applications disponibles sont listées
dans /usr/ports
La "liste" dans ports correspond à l'état des ports à un instant
donné. Pour mettre à jour les applications installées, il faut mettre
à jour cette liste. On passe encore par cvsup. Après par contre, il y
a plusieures solutions pour mettre à jour un ou plusieures ports.
Il y a les solutions "à la main" desinstalle/reinstalle. La solution à
peine mieux de pkg_version (mais je crois que l'option qui engendrait
un script de mise à jour tout fait a été suprimé.) Et les solutions
comme portupgrade, qui finalement font à peine plus, mais ce à peine
fait toute la différence (trie en fonction de dépendances, sauvegardes
... )
On peut aussi mettre à jour les ports via binaire (portupgrade -P par
exemple), mais comme pour la base, il faut que ces binaires soient
disponibles.
Enfin, on notera que l'évolution des ports est totalement indépendante
de la base et par conséquent les versions des ports installés ne
dépendent pas de la version de la base installée.
4 ) Quelle différence y-a-t-il entre portupgrade -a et portupgrade
-ar(R) ? Pour un port donné, ses dépendances se verront également mis à
jour recursivement, puisqu'elles sont à priori listées quand je
'pkg_version -vl "<"'
Il existe parfois des cas un peu compliqué de mise à jour où un port
est "à jour" (il n'est pas listé par pkg_version ou portversion) mais
doit être recompilé pour correspondre à un autre port qui lui a été (ou
va être) mis à jour.
Je ne sais pas si portupgrade gère tout seul (dans tous les cas) ce
genre de chose maintenant, le plus sûr est de coller le "-r"
systématiquement au lorsque l'on fait un portupgrade "-a". Le "-R"
peut aussi être nécessaire ou utile s'il y a une nouvelle dépendance
et que l'on utilise l'option "-P".
5 ) Parfois, en éditant une commande (pas nécessairement très longue)
sous xterm(que je sois en plein écran ou, par défaut, en 80*24), le
retour chariot ne se fait pas naturellement (comme s'il y avait une
frontière invisible) et la commande empiète par la suite sur mon prompt
(à la même ligne) si bien qu'à la fin, je vois plus ce que j'ai tapé. Je
dois alors fermer le xterm et en ouvrir un autre.
Je n'utilise plus xterm depuis longtemps ... rxvt se comporte "mieux"
pour moi ;)
m'étant mis à FreeBSD depuis environ un mois, j'ai passé pas mal de temps à lire de la doc après avoir installé la release 6.2. Il subsiste des questions sans réponses. Je les livre en l'état, en essayant d'éliminer les grosses anneries...
Félicitations ! Tant pour le choix que pour la méthode de travail ;)
1 ) Pour mettre a jour les sources du système on mentionne souvent cvsup, qu'en est-il de freebsd-update? A-t'il le même rôle que cvsup ? Doit-on l'utiliser régulièrement comme portupgrade ?
2 ) N'ayant jamais utilisé cvsup, je n'ai fait qu'utiliser portupgrade et je devine que mon système ne peut se voir apposer aucune des étiquettes CVS connues (releng,current/stable). Y'a-t-il une dénomination/catégorie pour ce système ? Est-il exacte de dire que je suis toujours en 6.2_RELEASE (c'est enfait la sortie de uname -r)?
3 ) Mettons que je mette à jour mes sources avec cvsup, comment le système fait-il pour déterminer les ports que je pourrai mettre à jour par la suite ? Enfait est ce que le choix d'une étiquette influence la disponibilité de tel ou tel logiciel porté ?
Bon, je vais faire une réponse "générique" sur la mise à jour.
Dans FreeBSD (et dans Net et Open également) il y a une séparation "forte" entre le système (le minimum nécessaire ou presque) que l'on appelle la base et les "applications tiers" (les ports/pkg.)
Outre les binaires et bibliothèque de la base, on retrouve la base sous forme de sources dans /usr/src. Ces sources peuvent être utilisées pour compiler un noyeau spécifique ou mettre à jour le système (la base donc.)
Pour mettre à jour le système, on commence par mettre à jour les sources, en général avec cvsup. Une fois ces sources à jour (ou en tout cas à jour par rapport à une versio, ou un tag donné) on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente et globalement sûre (si on est sûre de sa machine et de la version récupérée.) Je vous conseille de lire la doc sur le sujet avant de vous lancer dedans, mais une fois que l'on l'a fait une fois, on se rend compte que ce n'est pas bien compliqué (moins que ce que la verbosité de la doc pourrait laisser croire.)
Il existe d'autre méthode pour mettre à jour la base, donc notamment freebsd-update qui utilise une mise à jour binaire. Mais pour qu'une mise à jour binaire soit possible il faut que ces binaires existent. Je n'ai jamais creusé la question freebsd-update, mais je suppose qu'il n'est pas vraiment possible de suivre STABLE ou CURRENT avec ça ... Par contre, je suppose que cela permet de se mettre à jour rapidement (la recompile du monde, c'est long.)
Pour les ports, les choses sont à la fois similaires et différentes. Les ports (et les pkg) "existent" sur un système installé de 2 façon: les applications installées sont répertoriées dans /var/db/pkg et l'ensemble des applications disponibles sont listées dans /usr/ports
La "liste" dans ports correspond à l'état des ports à un instant donné. Pour mettre à jour les applications installées, il faut mettre à jour cette liste. On passe encore par cvsup. Après par contre, il y a plusieures solutions pour mettre à jour un ou plusieures ports.
Il y a les solutions "à la main" desinstalle/reinstalle. La solution à peine mieux de pkg_version (mais je crois que l'option qui engendrait un script de mise à jour tout fait a été suprimé.) Et les solutions comme portupgrade, qui finalement font à peine plus, mais ce à peine fait toute la différence (trie en fonction de dépendances, sauvegardes ... )
On peut aussi mettre à jour les ports via binaire (portupgrade -P par exemple), mais comme pour la base, il faut que ces binaires soient disponibles.
Enfin, on notera que l'évolution des ports est totalement indépendante de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
4 ) Quelle différence y-a-t-il entre portupgrade -a et portupgrade -ar(R) ? Pour un port donné, ses dépendances se verront également mis à jour recursivement, puisqu'elles sont à priori listées quand je 'pkg_version -vl "<"'
Il existe parfois des cas un peu compliqué de mise à jour où un port est "à jour" (il n'est pas listé par pkg_version ou portversion) mais doit être recompilé pour correspondre à un autre port qui lui a été (ou va être) mis à jour.
Je ne sais pas si portupgrade gère tout seul (dans tous les cas) ce genre de chose maintenant, le plus sûr est de coller le "-r" systématiquement au lorsque l'on fait un portupgrade "-a". Le "-R" peut aussi être nécessaire ou utile s'il y a une nouvelle dépendance et que l'on utilise l'option "-P".
5 ) Parfois, en éditant une commande (pas nécessairement très longue) sous xterm(que je sois en plein écran ou, par défaut, en 80*24), le retour chariot ne se fait pas naturellement (comme s'il y avait une frontière invisible) et la commande empiète par la suite sur mon prompt (à la même ligne) si bien qu'à la fin, je vois plus ce que j'ai tapé. Je dois alors fermer le xterm et en ouvrir un autre.
Je n'utilise plus xterm depuis longtemps ... rxvt se comporte "mieux" pour moi ;)
-- Marwan Burelle.
patpro ~ patrick proniewski
In article , Marwan Burelle wrote:
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
Enfin, on notera que l'évolution des ports est totalement indépendante de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
patpro
-- http://www.patpro.net/
In article <slrnf56o3k.2if.burelle@melkor.kh405.net>,
Marwan Burelle <burelle@kh405.net> wrote:
on peut
reconstruire (globalement on recompile) "le monde". Cette phase est
lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel,
ok)
Enfin, on notera que l'évolution des ports est totalement indépendante
de la base et par conséquent les versions des ports installés ne
dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le
kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou
il fallait recompiller les ports (mais ce souvenir est vraiment
vague...).
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
Enfin, on notera que l'évolution des ports est totalement indépendante de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
patpro
-- http://www.patpro.net/
Marwan Burelle
In article , patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
un petit quart d'heure ? pour quelle machine ?
make buildworld prend au moins 30 à 40 min sur ma station ...
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Une update prend mini une heure et surtout (c'est le plus génant) nécessite une interraction de temps en temps.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
La version des ports est indépendantes (à quelques détails près) de la base, pas les binaires installées qui eux dépendent des lib de la base et donc peuvent nécessiter une recompilation lors d'un passage de version ...
Sans compter les ports qui nécessitent une version particulières ou une option du noyau ...
-- Marwan Burelle.
In article <patpro-66F529.23422222052007@news-1.proxad.net>,
patpro ~ patrick proniewski wrote:
In article <slrnf56o3k.2if.burelle@melkor.kh405.net>,
Marwan Burelle <burelle@kh405.net> wrote:
on peut
reconstruire (globalement on recompile) "le monde". Cette phase est
lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel,
ok)
un petit quart d'heure ? pour quelle machine ?
make buildworld prend au moins 30 à 40 min sur ma station ...
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Une update prend mini une heure et surtout (c'est le plus génant)
nécessite une interraction de temps en temps.
lsof peut râler de temps en temps si il n'est pas synchro avec le
kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou
il fallait recompiller les ports (mais ce souvenir est vraiment
vague...).
La version des ports est indépendantes (à quelques détails près) de la
base, pas les binaires installées qui eux dépendent des lib de la base
et donc peuvent nécessiter une recompilation lors d'un passage de
version ...
Sans compter les ports qui nécessitent une version particulières ou
une option du noyau ...
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
un petit quart d'heure ? pour quelle machine ?
make buildworld prend au moins 30 à 40 min sur ma station ...
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Une update prend mini une heure et surtout (c'est le plus génant) nécessite une interraction de temps en temps.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
La version des ports est indépendantes (à quelques détails près) de la base, pas les binaires installées qui eux dépendent des lib de la base et donc peuvent nécessiter une recompilation lors d'un passage de version ...
Sans compter les ports qui nécessitent une version particulières ou une option du noyau ...
-- Marwan Burelle.
patpro ~ patrick proniewski
In article , Marwan Burelle wrote:
un petit quart d'heure ? pour quelle machine ?
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail, ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
je ne les compte pas, 15 min c'est mon make buildworld uniquement. Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15 min (pas de -j, mais faudrait peut être que j'essaye)
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, ...
La version des ports est indépendantes (à quelques détails près) de la base, pas les binaires installées
ha oui ! mea culpa, je t'avais mal lu.
patpro
-- http://www.patpro.net/
In article <slrnf56q3h.2qp.burelle@melkor.kh405.net>,
Marwan Burelle <burelle@kh405.net> wrote:
un petit quart d'heure ? pour quelle machine ?
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail,
ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
je ne les compte pas, 15 min c'est mon make buildworld uniquement.
Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15
min (pas de -j, mais faudrait peut être que j'essaye)
lsof peut râler de temps en temps si il n'est pas synchro avec le
kernel, ...
La version des ports est indépendantes (à quelques détails près) de la
base, pas les binaires installées
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail, ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
je ne les compte pas, 15 min c'est mon make buildworld uniquement. Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15 min (pas de -j, mais faudrait peut être que j'essaye)
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, ...
La version des ports est indépendantes (à quelques détails près) de la base, pas les binaires installées
ha oui ! mea culpa, je t'avais mal lu.
patpro
-- http://www.patpro.net/
Laurent
On 22 mai, 23:42, patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
Et avec du smp c'est encore mieux :)
Enfin, on notera que l'évolution des ports est totalement indépenda nte de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
C'était peut-être moi. J'en avais parlé ici lors de mon passage de 5.4 a 6.1. stderr me renvoyais nombre de messages watchdog et le systême était relativement lent. Il s'est avéré que mon portupgrade -a n'avais pas pleinement fixé la correspondances des ports avec les nouvelles bibliothèques systèmes, un second portupgrade avais résolu le problème.
-- Laurent C.
On 22 mai, 23:42, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
In article <slrnf56o3k.2if.bure...@melkor.kh405.net>,
Marwan Burelle <bure...@kh405.net> wrote:
on peut
reconstruire (globalement on recompile) "le monde". Cette phase est
lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel,
ok)
Et avec du smp c'est encore mieux :)
Enfin, on notera que l'évolution des ports est totalement indépenda nte
de la base et par conséquent les versions des ports installés ne
dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le
kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou
il fallait recompiller les ports (mais ce souvenir est vraiment
vague...).
C'était peut-être moi. J'en avais parlé ici lors de mon passage de 5.4
a 6.1. stderr me renvoyais nombre de messages watchdog et le systême
était relativement lent. Il s'est avéré que mon portupgrade -a n'avais
pas pleinement fixé la correspondances des ports avec les nouvelles
bibliothèques systèmes, un second portupgrade avais résolu le
problème.
On 22 mai, 23:42, patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
Et avec du smp c'est encore mieux :)
Enfin, on notera que l'évolution des ports est totalement indépenda nte de la base et par conséquent les versions des ports installés ne dépendent pas de la version de la base installée.
lsof peut râler de temps en temps si il n'est pas synchro avec le kernel, et j'ai un vague souvenir d'un passage de 5 en 6 (je crois) ou il fallait recompiller les ports (mais ce souvenir est vraiment vague...).
C'était peut-être moi. J'en avais parlé ici lors de mon passage de 5.4 a 6.1. stderr me renvoyais nombre de messages watchdog et le systême était relativement lent. Il s'est avéré que mon portupgrade -a n'avais pas pleinement fixé la correspondances des ports avec les nouvelles bibliothèques systèmes, un second portupgrade avais résolu le problème.
-- Laurent C.
Laurent
On 23 mai, 00:33, patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
un petit quart d'heure ? pour quelle machine ?
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail, ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai bien passé une heure), le mergemaster de mise à jour de 6-STABLE est relativement rapide ;)
D'ailleurs aura-t-on la même procédure de mise à jour avec la version 7.0 ?
je ne les compte pas, 15 min c'est mon make buildworld uniquement. Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15 min (pas de -j, mais faudrait peut être que j'essaye)
J'utilise -j pour make buildkernel depuis des mois sans aucun problème, et le gain (en smp) est non négligeable.
-- Laurent C.
On 23 mai, 00:33, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
In article <slrnf56q3h.2qp.bure...@melkor.kh405.net>,
Marwan Burelle <bure...@kh405.net> wrote:
un petit quart d'heure ? pour quelle machine ?
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail,
ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai bien
passé une heure), le mergemaster de mise à jour de 6-STABLE est
relativement rapide ;)
D'ailleurs aura-t-on la même procédure de mise à jour avec la version
7.0 ?
je ne les compte pas, 15 min c'est mon make buildworld uniquement.
Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15
min (pas de -j, mais faudrait peut être que j'essaye)
J'utilise -j pour make buildkernel depuis des mois sans aucun
problème, et le gain (en smp) est non négligeable.
On 23 mai, 00:33, patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
un petit quart d'heure ? pour quelle machine ?
bi-sossaman 1,6 GHz (4 cores donc) et 1Go de RAM. Compil avec -j12.
make buildworld prend au moins 30 à 40 min sur ma station ...
j'ai neutralisé quelques trucs dans mon make.conf, quand meme (sendmail, ipv6, objC, ...)
Sans compter les reboots et le fastidieux mergemaster et ses questions ;)
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai bien passé une heure), le mergemaster de mise à jour de 6-STABLE est relativement rapide ;)
D'ailleurs aura-t-on la même procédure de mise à jour avec la version 7.0 ?
je ne les compte pas, 15 min c'est mon make buildworld uniquement. Là ou je perds du temps c'est sur le make buildkernel qui prend aussi 15 min (pas de -j, mais faudrait peut être que j'essaye)
J'utilise -j pour make buildkernel depuis des mois sans aucun problème, et le gain (en smp) est non négligeable.
-- Laurent C.
patpro ~ Patrick Proniewski
In article , Laurent wrote:
On 22 mai, 23:42, patpro ~ patrick proniewski wrote:
In article , Marwan Burelle wrote:
on peut reconstruire (globalement on recompile) "le monde". Cette phase est lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel, ok)
Et avec du smp c'est encore mieux :)
ho ben j'ai quand même 4 cores sur mon SMP ;) mais bon, c'est de la basse consommation, et "que" 1.6 GHz.
patpro
-- http://www.patpro.net/
In article <1179909398.915746.35580@p77g2000hsh.googlegroups.com>,
Laurent <laurent.bar@gmail.com> wrote:
On 22 mai, 23:42, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
In article <slrnf56o3k.2if.bure...@melkor.kh405.net>,
Marwan Burelle <bure...@kh405.net> wrote:
on peut
reconstruire (globalement on recompile) "le monde". Cette phase est
lente
mais non mais non, un petit quart d'heure (plus un autre pour le kernel,
ok)
Et avec du smp c'est encore mieux :)
ho ben j'ai quand même 4 cores sur mon SMP ;)
mais bon, c'est de la basse consommation, et "que" 1.6 GHz.
À (at) Wed, 23 May 2007 12:03:23 +0200, patpro ~ Patrick Proniewski écrivait (wrote):
Bon, j'ai refait un bench rapide pour le make buildkernel :
pas de j -> real 10m29.278s user 9m27.748s sys 1m10.010s
-j8 -> real 5m57.258s user 9m41.743s sys 1m42.163s
-j12 -> real 6m0.669s user 9m41.772s sys 1m42.083s
un gain sensible donc, mais pas faramineux.
Un gain proche de 50%, je trouve ça faramineux ! Sur le 'buildworld', c'est bien aussi. ;-)
Le gain s'explique presque uniquement pas le goulet d'étranglement que constitue l'accès au disque.
Et je n'ai pas tenté de booter sur le kernel -j* ;)
Depuis la 5.1, j'utilise toujours -j (avec des valeurs adaptées pifométriquement selon les machines) et je n'ai jamais eu de problèmes.
Je rêve du jour où les ports le proposeront au moins en option (débrayable au cas par cas).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Marwan Burelle
In article , Laurent wrote:
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai bien passé une heure), le mergemaster de mise à jour de 6-STABLE est relativement rapide ;)
Je n'ai pas essayé le mergemaster entre version ... en général, vu que mes machines sont bien partitionnées, je fais des réinstalle pour les changements majeurs de release. C'est tout aussi rapide et tout aussi sûr ...
Mais, ma remarque sur mergemaster est plutôt une remarque sur le temps perdu à répondre à des questions sur des fichiers dont on se contrefout.
Typiquement, la plus part des utilisateurs ne touche pas (ils font bien) à /etc/default, /etc/periodic ou aux scripts rc.* ...
Il manque à mergemaster la possibilité de lister les fichiers à remplacer sans poser de question. J'avais regardé le code, mais c'est quand même assez lourd à lire et à modifier ... je n'ai pas eu le courrage d'aller plus loin ...
-- Marwan Burelle.
In article <1179909792.794387.57530@p47g2000hsd.googlegroups.com>,
Laurent wrote:
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai
bien passé une heure), le mergemaster de mise à jour de 6-STABLE est
relativement rapide ;)
Je n'ai pas essayé le mergemaster entre version ... en général, vu que
mes machines sont bien partitionnées, je fais des réinstalle pour les
changements majeurs de release. C'est tout aussi rapide et tout aussi
sûr ...
Mais, ma remarque sur mergemaster est plutôt une remarque sur le temps
perdu à répondre à des questions sur des fichiers dont on se
contrefout.
Typiquement, la plus part des utilisateurs ne touche pas (ils font
bien) à /etc/default, /etc/periodic ou aux scripts rc.* ...
Il manque à mergemaster la possibilité de lister les fichiers à
remplacer sans poser de question. J'avais regardé le code, mais c'est
quand même assez lourd à lire et à modifier ... je n'ai pas eu le
courrage d'aller plus loin ...
Quand on a connu un mergemaster de passage de 5.x a 6.x (ou j'ai bien passé une heure), le mergemaster de mise à jour de 6-STABLE est relativement rapide ;)
Je n'ai pas essayé le mergemaster entre version ... en général, vu que mes machines sont bien partitionnées, je fais des réinstalle pour les changements majeurs de release. C'est tout aussi rapide et tout aussi sûr ...
Mais, ma remarque sur mergemaster est plutôt une remarque sur le temps perdu à répondre à des questions sur des fichiers dont on se contrefout.
Typiquement, la plus part des utilisateurs ne touche pas (ils font bien) à /etc/default, /etc/periodic ou aux scripts rc.* ...
Il manque à mergemaster la possibilité de lister les fichiers à remplacer sans poser de question. J'avais regardé le code, mais c'est quand même assez lourd à lire et à modifier ... je n'ai pas eu le courrage d'aller plus loin ...
