nouvel utilisateur de freebsd, j'ai voulu profiter de l'été pour mettre à jour une 8.0 en 8.1-RELEASE
j'ai donc suivi la documentation de http://www.freebsd.org/releases/8.1R/announce.html
pour faire les freebsd-update. impeccable
ensuite, pkg_version m'a indiqué les reste des ports à mettre à jour et j'ai lancé la commande
"portupgrade -aPPR", en espérant gagner du temps en utilisant les logiciels pre-compilés.
et ce fut long, très long, trop long (quasi 24 h pour 400 packages environ).
In article <1jmrh8s.1mqlcligxfl2gN%, Xavier wrote:
Paul Gaborit wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux faire les mises à jour via les sources (en recompilant les ports donc).
J'opine. Beaucoup de personnes ici préconisent les mises à jour par packages, mais je préfère compiler. Tiens, un exemple pour justifier mon choix : Postfix n'est pas compilé par défaut avec SASL/Dovecot, alors que Dovecot est mon serveur POP/IMAP de choix, et que, à côté de Cyrus-SASL, c'est d'une simplicité biblique, v/s la boîte d'aspirine :-)
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont pas serieuses, ca peut pas marcher.
In article <1jmrh8s.1mqlcligxfl2gN%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> wrote:
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux
faire les mises à jour via les sources (en recompilant les ports
donc).
J'opine. Beaucoup de personnes ici préconisent les mises à jour par
packages, mais je préfère compiler. Tiens, un exemple pour justifier mon
choix : Postfix n'est pas compilé par défaut avec SASL/Dovecot, alors
que Dovecot est mon serveur POP/IMAP de choix, et que, à côté de
Cyrus-SASL, c'est d'une simplicité biblique, v/s la boîte d'aspirine :-)
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont
pas serieuses, ca peut pas marcher.
In article <1jmrh8s.1mqlcligxfl2gN%, Xavier wrote:
Paul Gaborit wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux faire les mises à jour via les sources (en recompilant les ports donc).
J'opine. Beaucoup de personnes ici préconisent les mises à jour par packages, mais je préfère compiler. Tiens, un exemple pour justifier mon choix : Postfix n'est pas compilé par défaut avec SASL/Dovecot, alors que Dovecot est mon serveur POP/IMAP de choix, et que, à côté de Cyrus-SASL, c'est d'une simplicité biblique, v/s la boîte d'aspirine :-)
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont pas serieuses, ca peut pas marcher.
espie
In article <i3eqt3$8t$, Patrick Lamaizière wrote:
gerbier :
quels sont les arguments techniques pour une mise a jour depuis les
sources plutot que par packages
binaires ?
C'est pour faire rire les openBSDistes.
Zut, tu me gaches mes effets. Mais c'est vrai que ca m'amuse toujours beaucoup.
In article <i3eqt3$8t$1@news.davenulle.org>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
gerbier :
quels sont les arguments techniques pour une mise a jour depuis les
sources plutot que par packages
binaires ?
C'est pour faire rire les openBSDistes.
Zut, tu me gaches mes effets. Mais c'est vrai que ca m'amuse toujours
beaucoup.
quels sont les arguments techniques pour une mise a jour depuis les
sources plutot que par packages
binaires ?
C'est pour faire rire les openBSDistes.
Zut, tu me gaches mes effets. Mais c'est vrai que ca m'amuse toujours beaucoup.
Paul Gaborit
À (at) Thu, 05 Aug 2010 17:42:52 +0200, gerbier écrivait (wrote):
Paul Gaborit wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux faire les mises à jour via les sources (en recompilant les ports donc). Plus on le fait régulièrement et moins ça dure longtemps (en tous cas, c'est le sentiment que ça donne ;-)).
venant du monde linux et étant habitué à utiliser des packages binaires (deb, rpm), j'ai l'impression d'avoir une gentoo :)
quels sont les arguments techniques pour une mise a jour depuis les sources plutot que par packages binaires ?
L'intérêt ? Dans l'absolu; aucun. En pratique, ça marche bien et on a des version récentes des softs alors que les pacakges binaires ne sont mis à jour que très rarement et pas toujours de manière cohérente (en tous cas, c'était comme ça la dernière fois que j'ai essayé).
Avant de faire une mise à jour, lire attentivement /usr/ports/UPDATING. Après avoir fait ce qui est recommandé pour certaines mises à jour délicates, on peut appliquer les autres mises à jour (via compilation) :
il y a quand meme 9057 lignes !
Oui mais c'est incrémental. Si on regarde régulièrement, il n'y a que le début qui est utile. Et puis, on ne s'intéresse qu'aux packages installés. En gros, pour mon serveur qui gère un millier de ports, je trouve environ un message par mois qui me concerne.
De manière plus générale, sur cet aspect, FreeBSD semble archaïque comparé à ce qui se fait sur Linux ou OpenBSD. Et cela ne semble pas prêt d'évoluer malgré les relances régulières de Michel Talon sur la question. Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 05 Aug 2010 17:42:52 +0200,
gerbier <eric_nospam_gerbier@meteo.fr.invalid> écrivait (wrote):
Paul Gaborit wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux
faire les mises à jour via les sources (en recompilant les ports
donc). Plus on le fait régulièrement et moins ça dure longtemps (en tous
cas, c'est le sentiment que ça donne ;-)).
venant du monde linux et étant habitué à utiliser des packages
binaires (deb, rpm), j'ai l'impression d'avoir une gentoo :)
quels sont les arguments techniques pour une mise a jour depuis les
sources plutot que par packages binaires ?
L'intérêt ? Dans l'absolu; aucun. En pratique, ça marche bien et on a
des version récentes des softs alors que les pacakges binaires ne sont
mis à jour que très rarement et pas toujours de manière cohérente (en
tous cas, c'était comme ça la dernière fois que j'ai essayé).
Avant de faire une mise à jour, lire attentivement
/usr/ports/UPDATING. Après avoir fait ce qui est recommandé pour
certaines mises à jour délicates, on peut appliquer les autres mises à
jour (via compilation) :
il y a quand meme 9057 lignes !
Oui mais c'est incrémental. Si on regarde régulièrement, il n'y a que le
début qui est utile. Et puis, on ne s'intéresse qu'aux packages
installés. En gros, pour mon serveur qui gère un millier de ports, je
trouve environ un message par mois qui me concerne.
De manière plus générale, sur cet aspect, FreeBSD semble archaïque
comparé à ce qui se fait sur Linux ou OpenBSD. Et cela ne semble pas
prêt d'évoluer malgré les relances régulières de Michel Talon sur la
question. Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour
réécrire le système de ports.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 05 Aug 2010 17:42:52 +0200, gerbier écrivait (wrote):
Paul Gaborit wrote:
Mais, en l'état actuel du système de ports de FreeBSD, il vaut mieux faire les mises à jour via les sources (en recompilant les ports donc). Plus on le fait régulièrement et moins ça dure longtemps (en tous cas, c'est le sentiment que ça donne ;-)).
venant du monde linux et étant habitué à utiliser des packages binaires (deb, rpm), j'ai l'impression d'avoir une gentoo :)
quels sont les arguments techniques pour une mise a jour depuis les sources plutot que par packages binaires ?
L'intérêt ? Dans l'absolu; aucun. En pratique, ça marche bien et on a des version récentes des softs alors que les pacakges binaires ne sont mis à jour que très rarement et pas toujours de manière cohérente (en tous cas, c'était comme ça la dernière fois que j'ai essayé).
Avant de faire une mise à jour, lire attentivement /usr/ports/UPDATING. Après avoir fait ce qui est recommandé pour certaines mises à jour délicates, on peut appliquer les autres mises à jour (via compilation) :
il y a quand meme 9057 lignes !
Oui mais c'est incrémental. Si on regarde régulièrement, il n'y a que le début qui est utile. Et puis, on ne s'intéresse qu'aux packages installés. En gros, pour mon serveur qui gère un millier de ports, je trouve environ un message par mois qui me concerne.
De manière plus générale, sur cet aspect, FreeBSD semble archaïque comparé à ce qui se fait sur Linux ou OpenBSD. Et cela ne semble pas prêt d'évoluer malgré les relances régulières de Michel Talon sur la question. Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
xavier
Marc Espie wrote:
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont pas serieuses, ca peut pas marcher.
Chez Open, le package binaire de Postfix est compilé par défaut avec le support de Dovecot/SASL ?
Ou bien alors :
<mauvaise langue> Postfix est trop moderne, Open reste à Sendmail ? </>
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages de Debian :-) Impossible de se débarasser de ce truc la dernière fois que j'ai testé Linusque.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Marc Espie <espie@lain.home> wrote:
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont
pas serieuses, ca peut pas marcher.
Chez Open, le package binaire de Postfix est compilé par défaut avec le
support de Dovecot/SASL ?
Ou bien alors :
<mauvaise langue>
Postfix est trop moderne, Open reste à Sendmail ?
</>
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages
de Debian :-) Impossible de se débarasser de ce truc la dernière fois
que j'ai testé Linusque.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Forcement, apres, si t'utilise un bsd ou les options par defaut ne sont pas serieuses, ca peut pas marcher.
Chez Open, le package binaire de Postfix est compilé par défaut avec le support de Dovecot/SASL ?
Ou bien alors :
<mauvaise langue> Postfix est trop moderne, Open reste à Sendmail ? </>
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages de Debian :-) Impossible de se débarasser de ce truc la dernière fois que j'ai testé Linusque.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
xavier
Patrick Lamaizière wrote:
Et à éviter les mises à jours merdique genre cups / xorg, ou un mois après.
Ou bien php5 (5.3.2 -> 5.3.3, de mémpoire) que j'avais été obligé de marquer "hold" dans mon précédent taf, parce que la version de SPIP qu'on avait ne le supportait pas....
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les dépendances ad-hoc, parce que même sur un serveur headless, un truc aussi con que xclock ne marche pas sur un hôte distant sans xorg-minimal, ce qui ne devrait pas être le cas.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Patrick Lamaizière <adresse@est.invalid> wrote:
Et à éviter les mises à jours merdique genre cups / xorg, ou un mois
après.
Ou bien php5 (5.3.2 -> 5.3.3, de mémpoire) que j'avais été obligé de
marquer "hold" dans mon précédent taf, parce que la version de SPIP
qu'on avait ne le supportait pas....
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les
dépendances ad-hoc, parce que même sur un serveur headless, un truc
aussi con que xclock ne marche pas sur un hôte distant sans
xorg-minimal, ce qui ne devrait pas être le cas.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Et à éviter les mises à jours merdique genre cups / xorg, ou un mois après.
Ou bien php5 (5.3.2 -> 5.3.3, de mémpoire) que j'avais été obligé de marquer "hold" dans mon précédent taf, parce que la version de SPIP qu'on avait ne le supportait pas....
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les dépendances ad-hoc, parce que même sur un serveur headless, un truc aussi con que xclock ne marche pas sur un hôte distant sans xorg-minimal, ce qui ne devrait pas être le cas.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
talon
Xavier wrote:
Patrick Lamaizière wrote:
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les dépendances ad-hoc, parce que même sur un serveur headless, un truc aussi con que xclock ne marche pas sur un hôte distant sans xorg-minimal, ce qui ne devrait pas être le cas.
Xorg c'est l'horreur absolue dans les nouvelles versions de FreeBSD. Il n'y a absolument aucune aide pour faire tourner le bouzin, perso je viens de réinstaller ma machine de bureau à neuf, j'ai passé au moins une heure pour voir X tourner, et deux jours pour avoir mon environnement à peu près fonctionnel. C'est pas avec des performances de ce genre que FreeBSD va gagner beaucoup de clients sur Linux, sauf peut être sur des serveurs (et dans ce domaine je ne suis pas sûr que les performances soient au même niveau que Linux). En fait je trouve que le système des ports est en train de partir en couille complète. A comparer avec une Ubuntu qu'on installe en une heure ou deux, et qui se tient à jour toute seule, cruelle comparaison.
Xavier <xavier@groumpf.org> wrote:
Patrick Lamaizière <adresse@est.invalid> wrote:
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les
dépendances ad-hoc, parce que même sur un serveur headless, un truc
aussi con que xclock ne marche pas sur un hôte distant sans
xorg-minimal, ce qui ne devrait pas être le cas.
Xorg c'est l'horreur absolue dans les nouvelles versions de FreeBSD.
Il n'y a absolument aucune aide pour faire tourner le bouzin, perso je
viens de réinstaller ma machine de bureau à neuf, j'ai passé au moins
une heure pour voir X tourner, et deux jours pour avoir mon
environnement à peu près fonctionnel. C'est pas avec des performances de
ce genre que FreeBSD va gagner beaucoup de clients sur Linux, sauf
peut être sur des serveurs (et dans ce domaine je ne suis pas sûr que
les performances soient au même niveau que Linux). En fait je trouve que
le système des ports est en train de partir en couille complète. A
comparer avec une Ubuntu qu'on installe en une heure ou deux, et qui se
tient à jour toute seule, cruelle comparaison.
Et en parlant de xorg, faudrait que les mainteneurs rajoutent les dépendances ad-hoc, parce que même sur un serveur headless, un truc aussi con que xclock ne marche pas sur un hôte distant sans xorg-minimal, ce qui ne devrait pas être le cas.
Xorg c'est l'horreur absolue dans les nouvelles versions de FreeBSD. Il n'y a absolument aucune aide pour faire tourner le bouzin, perso je viens de réinstaller ma machine de bureau à neuf, j'ai passé au moins une heure pour voir X tourner, et deux jours pour avoir mon environnement à peu près fonctionnel. C'est pas avec des performances de ce genre que FreeBSD va gagner beaucoup de clients sur Linux, sauf peut être sur des serveurs (et dans ce domaine je ne suis pas sûr que les performances soient au même niveau que Linux). En fait je trouve que le système des ports est en train de partir en couille complète. A comparer avec une Ubuntu qu'on installe en une heure ou deux, et qui se tient à jour toute seule, cruelle comparaison.
talon
Paul Gaborit wrote:
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon installation j'ai encore vu passer des dépendances ubuesques. Et a contrario, personne n'a été foutu de concocter un méta port pour Xorg qui marche de façon minimale sans aller pêcher à la ligne les ports nécessaires. Avec un système de dépendances dans un tel état, personne ne peut écrire un système de ports fonctionnel. A fortiori un système basé sur des paquets précompilés. Si tout le monde joue à trafiquer ses propres options, on n'est pas près d'avoir quelque chose de bien testé et qui marche. D'où les gadgets tels que "lire UPDATING" et autres monstruosités qui ne devraient exister sous aucun prétexte.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour
réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon
installation j'ai encore vu passer des dépendances ubuesques.
Et a contrario, personne n'a été foutu de concocter un méta port pour
Xorg qui marche de façon minimale sans aller pêcher à la ligne les ports
nécessaires. Avec un système de dépendances dans un tel état, personne
ne peut écrire un système de ports fonctionnel. A fortiori un système
basé sur des paquets précompilés. Si tout le monde joue à trafiquer ses
propres options, on n'est pas près d'avoir quelque chose de bien testé
et qui marche. D'où les gadgets tels que "lire UPDATING" et autres
monstruosités qui ne devraient exister sous aucun prétexte.
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon installation j'ai encore vu passer des dépendances ubuesques. Et a contrario, personne n'a été foutu de concocter un méta port pour Xorg qui marche de façon minimale sans aller pêcher à la ligne les ports nécessaires. Avec un système de dépendances dans un tel état, personne ne peut écrire un système de ports fonctionnel. A fortiori un système basé sur des paquets précompilés. Si tout le monde joue à trafiquer ses propres options, on n'est pas près d'avoir quelque chose de bien testé et qui marche. D'où les gadgets tels que "lire UPDATING" et autres monstruosités qui ne devraient exister sous aucun prétexte.
espie
In article <i3hcbd$bou$, Michel Talon wrote:
Paul Gaborit wrote:
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon installation j'ai encore vu passer des dépendances ubuesques.
Non, il vous manque un dictateur. Je peux t'assurer qu'il y aurait du grand n'importe-quoi dans les dependances d'OpenBSD et dans les options compilees si on ne faisait pas un peu de nettoyage de temps en temps.
Mais voila, on est quelques-uns a dire parfois aux gens "c'est n'importe quoi". Voire dans les cas extremes "bon ecoute, tu vas nous nettoyer tout ca si tu tiens a ton compte"...
L'air de rien, le fait de fournir des packages compiles "fait pression" pour garder le nombre d'options dans des proportions raisonnables.
Tout est histoire d'etat d'esprit. Tant que ca reste oriente a 100% developpeur qui bidouille ses trucs et qui est tout content quand enfin ca marche, tant que toutes les idees memes les plus connes ont droit de cite... ben...
In article <i3hcbd$bou$2@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour
réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon
installation j'ai encore vu passer des dépendances ubuesques.
Non, il vous manque un dictateur. Je peux t'assurer qu'il y aurait du
grand n'importe-quoi dans les dependances d'OpenBSD et dans les options
compilees si on ne faisait pas un peu de nettoyage de temps en temps.
Mais voila, on est quelques-uns a dire parfois aux gens "c'est n'importe
quoi". Voire dans les cas extremes "bon ecoute, tu vas nous nettoyer tout
ca si tu tiens a ton compte"...
L'air de rien, le fait de fournir des packages compiles "fait pression"
pour garder le nombre d'options dans des proportions raisonnables.
Tout est histoire d'etat d'esprit. Tant que ca reste oriente a 100%
developpeur qui bidouille ses trucs et qui est tout content quand enfin
ca marche, tant que toutes les idees memes les plus connes ont droit
de cite... ben...
Il manque à l'équipe FreeBSD l'équivalent d'un Marc Espie pour réécrire le système de ports.
Il manque surtout des mainteneurs de ports de qualité. Dans mon installation j'ai encore vu passer des dépendances ubuesques.
Non, il vous manque un dictateur. Je peux t'assurer qu'il y aurait du grand n'importe-quoi dans les dependances d'OpenBSD et dans les options compilees si on ne faisait pas un peu de nettoyage de temps en temps.
Mais voila, on est quelques-uns a dire parfois aux gens "c'est n'importe quoi". Voire dans les cas extremes "bon ecoute, tu vas nous nettoyer tout ca si tu tiens a ton compte"...
L'air de rien, le fait de fournir des packages compiles "fait pression" pour garder le nombre d'options dans des proportions raisonnables.
Tout est histoire d'etat d'esprit. Tant que ca reste oriente a 100% developpeur qui bidouille ses trucs et qui est tout content quand enfin ca marche, tant que toutes les idees memes les plus connes ont droit de cite... ben...
Bastien Durel
Le Thu, 05 Aug 2010 19:36:49 +0200, Xavier a écrit :
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages de Debian :-) Impossible de se débarasser de ce truc la dernière fois que j'ai testé Linusque.
Ce ne sont pas des dépendances à exim, mais à mail-transport-agent. Il faut juste en installer un autre si tu veux virer exim (c'est moins pire à l'heure qu'il est, mais quand j'ai voulu installer qmail, il a fallu que je fasse un package vide qui fournissait mail-transport-agent, pour ne pas désinstaller la moitié du reste)
-- Bastien
Le Thu, 05 Aug 2010 19:36:49 +0200, Xavier a écrit :
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages
de Debian :-) Impossible de se débarasser de ce truc la dernière fois
que j'ai testé Linusque.
Ce ne sont pas des dépendances à exim, mais à mail-transport-agent.
Il faut juste en installer un autre si tu veux virer exim (c'est moins
pire à l'heure qu'il est, mais quand j'ai voulu installer qmail, il a
fallu que je fasse un package vide qui fournissait mail-transport-agent,
pour ne pas désinstaller la moitié du reste)
Le Thu, 05 Aug 2010 19:36:49 +0200, Xavier a écrit :
Bon, c'est pas pire que la dépendance à Exim de la moitié des packages de Debian :-) Impossible de se débarasser de ce truc la dernière fois que j'ai testé Linusque.
Ce ne sont pas des dépendances à exim, mais à mail-transport-agent. Il faut juste en installer un autre si tu veux virer exim (c'est moins pire à l'heure qu'il est, mais quand j'ai voulu installer qmail, il a fallu que je fasse un package vide qui fournissait mail-transport-agent, pour ne pas désinstaller la moitié du reste)
