Malgré l'excellent bouquin "Cahiers de l'Admin" sur BSD (1ière
édition), je ne trouve pas le moyen d'upgrader mon FreeBSD 5.2.1 en 5.3.
J'ai tenté l'upgrade avec sysinstall, mais chaque connexion à un serveur
FTP me renvoie une erreur "can't find the 5.2.1-RELEASE distribution on
this FTP server"...
Autre question: où peut-on trouver les ports pour Gnome 2.8 et comment
l'installer.
Le Fri, 04 Mar 2005 17:26:49 +0100, Stephane Dupille écrivit:
cycbuff is good for you. Non, ça c'est bien pour les binaries, mais pour .fr, hein,
vu le volume, on va pas se boursoufler le zboub pour si peu.
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne dépassera jamais la quantité d'espace que tu veux y mettre.
Le Fri, 04 Mar 2005 17:26:49 +0100, Stephane Dupille écrivit:
cycbuff is good for you.
Non, ça c'est bien pour les binaries, mais pour .fr, hein,
vu le volume, on va pas se boursoufler le zboub pour si peu.
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le
nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne
dépassera jamais la quantité d'espace que tu veux y mettre.
Le Fri, 04 Mar 2005 17:26:49 +0100, Stephane Dupille écrivit:
cycbuff is good for you. Non, ça c'est bien pour les binaries, mais pour .fr, hein,
vu le volume, on va pas se boursoufler le zboub pour si peu.
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne dépassera jamais la quantité d'espace que tu veux y mettre.
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne dépassera jamais la quantité d'espace que tu veux y mettre.
Je n'ai jamais eu de problème d'espace, ni d'inodes avec fr. Simplement, par reflexe, j'augmente toujours la densité d'inodes dans /var/spool, même si je n'y met pas de serveur de news. Pour un serveur de mails, c'est pratique aussi.
-- Moi je dis : 3 lignes c'est suspect, c'est fait pour le GCU. -+- SP in Guide du Neuneu sur Usenet : Allez hop ! Au GNoUf -+-
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le
nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne
dépassera jamais la quantité d'espace que tu veux y mettre.
Je n'ai jamais eu de problème d'espace, ni d'inodes avec fr.
Simplement, par reflexe, j'augmente toujours la densité d'inodes dans
/var/spool, même si je n'y met pas de serveur de news. Pour un serveur
de mails, c'est pratique aussi.
--
Moi je dis : 3 lignes c'est suspect, c'est fait pour le GCU.
-+- SP in Guide du Neuneu sur Usenet : Allez hop ! Au GNoUf -+-
Ah, pas d'accord. Tu n'as pas besoin de te casser la tête sur le nombre d'inodes dispo, et en plus, tu peux t'assurer que ça ne dépassera jamais la quantité d'espace que tu veux y mettre.
Je n'ai jamais eu de problème d'espace, ni d'inodes avec fr. Simplement, par reflexe, j'augmente toujours la densité d'inodes dans /var/spool, même si je n'y met pas de serveur de news. Pour un serveur de mails, c'est pratique aussi.
-- Moi je dis : 3 lignes c'est suspect, c'est fait pour le GCU. -+- SP in Guide du Neuneu sur Usenet : Allez hop ! Au GNoUf -+-
Marwan Burelle
In article <422a1bde$0$30332$, Mathieu Arnold wrote:
Même pas, le fetchindex est devenu automatique lors d'un pkgdb ou d'un portupgrade. D'ailleurs, est-ce qu'il n'y a pas un léger risque d'incohérence entre
les ports récupérés par cvsup et l'index récupéré par make fetchindex ensuite, si un port a été mis à jour entre temps ? L'INDEX récupéré par make fetchindex est vieux d'au pire une ou deux
heures. (sauf si l'INDEX est cassé, dans ce cas la, c'est le dernier valide qui a été généré.)
Effectivement ...
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes, je lance souvent le cvsup le soir en partant du bureau, ce n'est pas long mais je n'ai pas toujours que ça à faire ... donc le lendemain matin paf, le fetchindex ne correspond pas forcément à ce que à mon arbre des ports ... )
En gros, il vaut mieux grouper cvsup avec la commande pour reconstruire (ou télécharger) l'index.
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
C'est plus sûre.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <422a1bde$0$30332$626a14ce@news.free.fr>, Mathieu Arnold wrote:
Même pas, le fetchindex est devenu automatique lors d'un pkgdb ou
d'un portupgrade.
D'ailleurs, est-ce qu'il n'y a pas un léger risque d'incohérence entre
les ports récupérés par cvsup et l'index récupéré par make fetchindex
ensuite, si un port a été mis à jour entre temps ?
L'INDEX récupéré par make fetchindex est vieux d'au pire une ou deux
heures. (sauf si l'INDEX est cassé, dans ce cas la, c'est le dernier
valide qui a été généré.)
Effectivement ...
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on
se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes,
je lance souvent le cvsup le soir en partant du bureau, ce n'est pas
long mais je n'ai pas toujours que ça à faire ... donc le lendemain
matin paf, le fetchindex ne correspond pas forcément à ce que à mon
arbre des ports ... )
En gros, il vaut mieux grouper cvsup avec la commande pour
reconstruire (ou télécharger) l'index.
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
C'est plus sûre.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
In article <422a1bde$0$30332$, Mathieu Arnold wrote:
Même pas, le fetchindex est devenu automatique lors d'un pkgdb ou d'un portupgrade. D'ailleurs, est-ce qu'il n'y a pas un léger risque d'incohérence entre
les ports récupérés par cvsup et l'index récupéré par make fetchindex ensuite, si un port a été mis à jour entre temps ? L'INDEX récupéré par make fetchindex est vieux d'au pire une ou deux
heures. (sauf si l'INDEX est cassé, dans ce cas la, c'est le dernier valide qui a été généré.)
Effectivement ...
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes, je lance souvent le cvsup le soir en partant du bureau, ce n'est pas long mais je n'ai pas toujours que ça à faire ... donc le lendemain matin paf, le fetchindex ne correspond pas forcément à ce que à mon arbre des ports ... )
En gros, il vaut mieux grouper cvsup avec la commande pour reconstruire (ou télécharger) l'index.
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
C'est plus sûre.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Mathieu Arnold
Marwan Burelle écrivait:
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
Moi, j'aurais fait make update fetchindex :-)
-- Mathieu Arnold
Marwan Burelle écrivait:
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
Moi, j'aurais fait make update fetchindex :-)
Non. Pas quand tu met aussi à jour /usr/src par cvsup.
-- Laurent
Mathieu Arnold
Laurent Lefevre écrivait:
Mathieu Arnold writes:
Marwan Burelle écrivait:
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
Moi, j'aurais fait make update fetchindex :-)
Non. Pas quand tu met aussi à jour /usr/src par cvsup.
Y dit qu'il voit pas le rapport. make update dans /usr/ports n'a jamais touché /usr/src. De plus, make update dans /usr/src ne touche pas /usr/ports si on lui dit NO_PORTSUPDATE.
-- Mathieu Arnold
Laurent Lefevre écrivait:
Mathieu Arnold <mat@FreeBSD.org> writes:
Marwan Burelle écrivait:
Moi je fais ça :
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
Moi, j'aurais fait make update fetchindex :-)
Non. Pas quand tu met aussi à jour /usr/src par cvsup.
Y dit qu'il voit pas le rapport. make update dans /usr/ports n'a jamais
touché /usr/src. De plus, make update dans /usr/src ne touche pas
/usr/ports si on lui dit NO_PORTSUPDATE.
# cvsup -g -L 2 portsupfile && cd /usr/ports && make fetchindex
Moi, j'aurais fait make update fetchindex :-)
Non. Pas quand tu met aussi à jour /usr/src par cvsup.
Y dit qu'il voit pas le rapport. make update dans /usr/ports n'a jamais touché /usr/src. De plus, make update dans /usr/src ne touche pas /usr/ports si on lui dit NO_PORTSUPDATE.
-- Mathieu Arnold
Christophe Cuq
Nicolas Le Scouarnec nospam. invalid> writes:
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je* décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et ~/news/db à partir de leurs sauvegardes :)
-- CHC
Nicolas Le Scouarnec <root@india.ath.cx. nospam. invalid> writes:
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et
faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je*
décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs
dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et
~/news/db à partir de leurs sauvegardes :)
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je* décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et ~/news/db à partir de leurs sauvegardes :)
-- CHC
F. Senault
Nicolas Le Scouarnec nospam. invalid> writes:
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je* décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et ~/news/db à partir de leurs sauvegardes :)
Tu sais que tu peux automatiser ça dans pkgtools.conf, avec :
Fred -- Toute ressemblance avec un message écrit par un être au moins aussi intelligent qu'un singe tapant sur une machine à écrire pour reproduire du Shakespeare serait purement fortuite; prière de prévenir en cas de miracle. (Jokeuse, sur #lacave)
Nicolas Le Scouarnec <root@india.ath.cx. nospam. invalid> writes:
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et
faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je*
décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs
dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et
~/news/db à partir de leurs sauvegardes :)
Tu sais que tu peux automatiser ça dans pkgtools.conf, avec :
Fred
--
Toute ressemblance avec un message écrit par un être au moins aussi
intelligent qu'un singe tapant sur une machine à écrire pour reproduire
du Shakespeare serait purement fortuite; prière de prévenir en cas de
miracle. (Jokeuse, sur #lacave)
Il vaut dire a portupgrade de ne pas s'en occuper, on sait jamais et faire la mise a jour a la main...
Ici aussi, il est bien en HOLD dans pkgtools.conf, mais lorsque *je* décide de faire une maj, je sauve ~/news/etc et ~/news/db ailleurs dans un tar et je fais un portupgrade -f
Et ça fonctionne très bien après avoir remis en place ~/news/etc et ~/news/db à partir de leurs sauvegardes :)
Tu sais que tu peux automatiser ça dans pkgtools.conf, avec :
Fred -- Toute ressemblance avec un message écrit par un être au moins aussi intelligent qu'un singe tapant sur une machine à écrire pour reproduire du Shakespeare serait purement fortuite; prière de prévenir en cas de miracle. (Jokeuse, sur #lacave)
espie
In article , Marwan Burelle wrote:
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes, je lance souvent le cvsup le soir en partant du bureau, ce n'est pas long mais je n'ai pas toujours que ça à faire ... donc le lendemain matin paf, le fetchindex ne correspond pas forcément à ce que à mon arbre des ports ... )
Plus je vois des jolis threads comme ca, qui parlent des outils FreeBSD, avec machin qui decouvre tel outil de mise-a-jour, et toutes les options de mise-a-jour et possibilite de non-synchro de ce qu'on fait, plus je m'estime satisfait de l'approche qu'on a prise dans OpenBSD. En particulier, d'avoir les FLAVORS qui vont bien pour eviter aux gens de tripatouiller dans les options de Makefile. Ou encore, de la difficulte de mettre a jour certains ports precis, comme postgresql, qu'on est en train de resoudre de facon assez generale. Ou encore, d'essayer d'eviter d'avoir trois bases de donnes differentes qui peuvent ne pas etre synchrones (ce qui se fait betement en s'assurant que les outils sont assez rapides meme avec le vieux format pkgdb).
Ah tiens, pub. Dans la version 3.7 d'OpenBSD, il y aura une locate database construite a partir des packages, d'ailleurs c'est deja dans certains snapshots.
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui comprennent directement les problemes de bibliotheques partagees et de dependances entre packages sans avoir a passer par une usine a gaz qui risque de desinstaller toute la machine par megarde...
In article <slrnd2oau1.vtm.burelle@pc5-179.lri.fr>,
Marwan Burelle <burelle@lri.fr> wrote:
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on
se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes,
je lance souvent le cvsup le soir en partant du bureau, ce n'est pas
long mais je n'ai pas toujours que ça à faire ... donc le lendemain
matin paf, le fetchindex ne correspond pas forcément à ce que à mon
arbre des ports ... )
Plus je vois des jolis threads comme ca, qui parlent des outils FreeBSD,
avec machin qui decouvre tel outil de mise-a-jour, et toutes les options
de mise-a-jour et possibilite de non-synchro de ce qu'on fait, plus je
m'estime satisfait de l'approche qu'on a prise dans OpenBSD. En particulier,
d'avoir les FLAVORS qui vont bien pour eviter aux gens de tripatouiller
dans les options de Makefile. Ou encore, de la difficulte de mettre a jour
certains ports precis, comme postgresql, qu'on est en train de resoudre
de facon assez generale. Ou encore, d'essayer d'eviter d'avoir trois bases
de donnes differentes qui peuvent ne pas etre synchrones (ce qui se fait
betement en s'assurant que les outils sont assez rapides meme avec le vieux
format pkgdb).
Ah tiens, pub. Dans la version 3.7 d'OpenBSD, il y aura une locate database
construite a partir des packages, d'ailleurs c'est deja dans
certains snapshots.
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui comprennent
directement les problemes de bibliotheques partagees et de dependances entre
packages sans avoir a passer par une usine a gaz qui risque de desinstaller
toute la machine par megarde...
Si l'appel à portupgrade ou à pkgdb n'est pas la foulée du cvsup, on se retrouve avec un INDEX trop récent (j'ai eu ce genre de problèmes, je lance souvent le cvsup le soir en partant du bureau, ce n'est pas long mais je n'ai pas toujours que ça à faire ... donc le lendemain matin paf, le fetchindex ne correspond pas forcément à ce que à mon arbre des ports ... )
Plus je vois des jolis threads comme ca, qui parlent des outils FreeBSD, avec machin qui decouvre tel outil de mise-a-jour, et toutes les options de mise-a-jour et possibilite de non-synchro de ce qu'on fait, plus je m'estime satisfait de l'approche qu'on a prise dans OpenBSD. En particulier, d'avoir les FLAVORS qui vont bien pour eviter aux gens de tripatouiller dans les options de Makefile. Ou encore, de la difficulte de mettre a jour certains ports precis, comme postgresql, qu'on est en train de resoudre de facon assez generale. Ou encore, d'essayer d'eviter d'avoir trois bases de donnes differentes qui peuvent ne pas etre synchrones (ce qui se fait betement en s'assurant que les outils sont assez rapides meme avec le vieux format pkgdb).
Ah tiens, pub. Dans la version 3.7 d'OpenBSD, il y aura une locate database construite a partir des packages, d'ailleurs c'est deja dans certains snapshots.
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui comprennent directement les problemes de bibliotheques partagees et de dependances entre packages sans avoir a passer par une usine a gaz qui risque de desinstaller toute la machine par megarde...
Christophe Cuq
"F. Senault" writes:
Tu sais que tu peux automatiser ça dans pkgtools.conf, avec :
Ah non, ça je ne savais pas. Ça va me faire gagner du temps. Bon, va falloir que je me plonge dans la doc, merci :)
-- CHC
"F. Senault" <fred@lacave.net> writes:
Tu sais que tu peux automatiser ça dans pkgtools.conf, avec :
Ah non, ça je ne savais pas. Ça va me faire gagner du temps.
Bon, va falloir que je me plonge dans la doc, merci :)
