Comment mettre facilement un package à jour sous OpenBSD ?
Un exemple concret :
Je suis actuellement en 3.5.
J'ai installé le package png-1.2.5p2 depuis le CD.
Or, il y a la version png-1.2.5p3 "qui vient de sortir".
Comment je fais pour passer de la version p2 à la p3 simplement et sans
perdre les dependances déjà existantes pour png ?
A+
--
HTML lesson #42:
The only legitimate use of the greatly loathed <BLINK> tag.
On Sun, 16 May 2004 09:35:26 +0400 Nicolas BERNE wrote:
Bonjour à tous,
Comment mettre facilement un package à jour sous OpenBSD ? Un exemple concret : Je suis actuellement en 3.5. J'ai installé le package png-1.2.5p2 depuis le CD. Or, il y a la version png-1.2.5p3 "qui vient de sortir". Comment je fais pour passer de la version p2 à la p3 simplement et sans perdre les dependances déjà existantes pour png ?
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Bon courage !
mips
On Sun, 16 May 2004 09:35:26 +0400
Nicolas BERNE <berne_dot_nicolas@wanadoo.fr.invalid> wrote:
Bonjour à tous,
Comment mettre facilement un package à jour sous OpenBSD ?
Un exemple concret :
Je suis actuellement en 3.5.
J'ai installé le package png-1.2.5p2 depuis le CD.
Or, il y a la version png-1.2.5p3 "qui vient de sortir".
Comment je fais pour passer de la version p2 à la p3 simplement et
sans perdre les dependances déjà existantes pour png ?
Bravo tu viens de trouver le gros point faible de l'arbre des ports
d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller,
ainsi que tous les ports qui en dependent.
On Sun, 16 May 2004 09:35:26 +0400 Nicolas BERNE wrote:
Bonjour à tous,
Comment mettre facilement un package à jour sous OpenBSD ? Un exemple concret : Je suis actuellement en 3.5. J'ai installé le package png-1.2.5p2 depuis le CD. Or, il y a la version png-1.2.5p3 "qui vient de sortir". Comment je fais pour passer de la version p2 à la p3 simplement et sans perdre les dependances déjà existantes pour png ?
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Bon courage !
mips
Arnaud Launay
Le Sun, 16 May 2004 18:39:25 +0200, mips écrivit:
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!? Ca alors, moi qui pensait qu'open c'etait fait pour etre un firewall, je suis decu, mais decuuuuuuuuuuuu !
Arnaud.
Le Sun, 16 May 2004 18:39:25 +0200, mips écrivit:
Bravo tu viens de trouver le gros point faible de l'arbre des ports
d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller,
ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!?
Ca alors, moi qui pensait qu'open c'etait fait pour etre un
firewall, je suis decu, mais decuuuuuuuuuuuu !
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!? Ca alors, moi qui pensait qu'open c'etait fait pour etre un firewall, je suis decu, mais decuuuuuuuuuuuu !
Arnaud.
mips
On Mon, 17 May 2004 06:50:01 +0000 (UTC) Arnaud Launay wrote:
Le Sun, 16 May 2004 18:39:25 +0200, mips écrivit:
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!? Ca alors, moi qui pensait qu'open c'etait fait pour etre un firewall, je suis decu, mais decuuuuuuuuuuuu !
Ah mais attends, tu ne sait pas tout, on a aussi Gnome !! Si si je t'assure !
mips
On Mon, 17 May 2004 06:50:01 +0000 (UTC)
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Le Sun, 16 May 2004 18:39:25 +0200, mips écrivit:
Bravo tu viens de trouver le gros point faible de l'arbre des
ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et
reinstaller, ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!?
Ca alors, moi qui pensait qu'open c'etait fait pour etre un
firewall, je suis decu, mais decuuuuuuuuuuuu !
Ah mais attends, tu ne sait pas tout, on a aussi Gnome !!
Si si je t'assure !
On Mon, 17 May 2004 06:50:01 +0000 (UTC) Arnaud Launay wrote:
Le Sun, 16 May 2004 18:39:25 +0200, mips écrivit:
Bravo tu viens de trouver le gros point faible de l'arbre des ports d'OpenBSD. Pour mettre a jour il faut le desinstaller et reinstaller, ainsi que tous les ports qui en dependent.
Ah bon, il y a autre chose que pf dans l'arbre des ports d'open ?!? Ca alors, moi qui pensait qu'open c'etait fait pour etre un firewall, je suis decu, mais decuuuuuuuuuuuu !
Ah mais attends, tu ne sait pas tout, on a aussi Gnome !! Si si je t'assure !
mips
espie
In article , Nicolas BERNE wrote:
Bonjour à tous,
Comment mettre facilement un package à jour sous OpenBSD ? Un exemple concret : Je suis actuellement en 3.5. J'ai installé le package png-1.2.5p2 depuis le CD. Or, il y a la version png-1.2.5p3 "qui vient de sortir". Comment je fais pour passer de la version p2 à la p3 simplement et sans perdre les dependances déjà existantes pour png ?
Pour l'instant, ca n'est pas tres possible. C'est tres haut sur ma liste
de choses a faire pour OpenBSD 3.6.
En deux parties: - permettre `fake-pkg-add', qui installera des bouts de packages (includes+libs) dans un coin du WRKDIR, histoire de pouvoir construire plein de choses sans devoir rien installer, ou de preparer tous les packages pour une upgrade pepere.
- pkg_add -r (replace) ou pkg_add -u (upgrade), avec comme principe que pkg_add -r verifie que le nouveau package remplace l'ancien sans douleur (e.g., meme contraintes de dependances), et pkg_add -u est pret a en faire plus, comme de garder des bibliotheques partagees (style, stubs de vieux packages). Pas mal de choses a faire avant ca: * unifier pkg_add/pkg_delete de facon a pouvoir `facilement' installer/desinstaller des bouts de trucs de facon safe. * uniformiser un peu l'infrastructure pour pouvoir virer la plupart des cas sociaux a la @exec/@unexec/@INSTALL. * marquer les packages `a enlever' quand ils ne serviront plus pour les stubs. * donner aux gens les outils pour que les numeros de versions de bibliotheques dynamiques soient mis a jour correctement. * prevoir les cas particuliers...
Bref, pas mal de boulot en perspective, mais c'est en cours...
In article <slrncadvcu.ko9.berne_dot_nicolas@melkor.zorglub.z>,
Nicolas BERNE <berne.nicolas@wanadoo.fr> wrote:
Bonjour à tous,
Comment mettre facilement un package à jour sous OpenBSD ?
Un exemple concret :
Je suis actuellement en 3.5.
J'ai installé le package png-1.2.5p2 depuis le CD.
Or, il y a la version png-1.2.5p3 "qui vient de sortir".
Comment je fais pour passer de la version p2 à la p3 simplement et sans
perdre les dependances déjà existantes pour png ?
Pour l'instant, ca n'est pas tres possible. C'est tres haut sur ma liste
de choses a faire pour OpenBSD 3.6.
En deux parties:
- permettre `fake-pkg-add', qui installera des bouts de packages
(includes+libs) dans un coin du WRKDIR, histoire de pouvoir construire
plein de choses sans devoir rien installer, ou de preparer tous les
packages pour une upgrade pepere.
- pkg_add -r (replace) ou pkg_add -u (upgrade), avec comme principe que
pkg_add -r verifie que le nouveau package remplace l'ancien sans douleur
(e.g., meme contraintes de dependances), et pkg_add -u est pret a en faire
plus, comme de garder des bibliotheques partagees (style, stubs de vieux
packages). Pas mal de choses a faire avant ca:
* unifier pkg_add/pkg_delete de facon a pouvoir `facilement'
installer/desinstaller des bouts de trucs de facon safe.
* uniformiser un peu l'infrastructure pour pouvoir virer la plupart des
cas sociaux a la @exec/@unexec/@INSTALL.
* marquer les packages `a enlever' quand ils ne serviront plus pour les
stubs.
* donner aux gens les outils pour que les numeros de versions de
bibliotheques dynamiques soient mis a jour correctement.
* prevoir les cas particuliers...
Bref, pas mal de boulot en perspective, mais c'est en cours...
Comment mettre facilement un package à jour sous OpenBSD ? Un exemple concret : Je suis actuellement en 3.5. J'ai installé le package png-1.2.5p2 depuis le CD. Or, il y a la version png-1.2.5p3 "qui vient de sortir". Comment je fais pour passer de la version p2 à la p3 simplement et sans perdre les dependances déjà existantes pour png ?
Pour l'instant, ca n'est pas tres possible. C'est tres haut sur ma liste
de choses a faire pour OpenBSD 3.6.
En deux parties: - permettre `fake-pkg-add', qui installera des bouts de packages (includes+libs) dans un coin du WRKDIR, histoire de pouvoir construire plein de choses sans devoir rien installer, ou de preparer tous les packages pour une upgrade pepere.
- pkg_add -r (replace) ou pkg_add -u (upgrade), avec comme principe que pkg_add -r verifie que le nouveau package remplace l'ancien sans douleur (e.g., meme contraintes de dependances), et pkg_add -u est pret a en faire plus, comme de garder des bibliotheques partagees (style, stubs de vieux packages). Pas mal de choses a faire avant ca: * unifier pkg_add/pkg_delete de facon a pouvoir `facilement' installer/desinstaller des bouts de trucs de facon safe. * uniformiser un peu l'infrastructure pour pouvoir virer la plupart des cas sociaux a la @exec/@unexec/@INSTALL. * marquer les packages `a enlever' quand ils ne serviront plus pour les stubs. * donner aux gens les outils pour que les numeros de versions de bibliotheques dynamiques soient mis a jour correctement. * prevoir les cas particuliers...
Bref, pas mal de boulot en perspective, mais c'est en cours...
Benjamin Pineau
Le Mon, 17 May 2004 21:29:31 +0000 (UTC), Marc Espie écrivais:
Bref, pas mal de boulot en perspective, mais c'est en cours...
Je saute sur l'occasion pour poser des questions qui me tarabustent depuis longtemps concernant les packages d'openbsd.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps). - Pourquoi les messages d'erreur de pkg_add sont ils affichés sur STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand l'installation à échouée ?).
Le Mon, 17 May 2004 21:29:31 +0000 (UTC),
Marc Espie <espie@tetto.gentiane.org> écrivais:
Bref, pas mal de boulot en perspective, mais c'est en cours...
Je saute sur l'occasion pour poser des questions qui me tarabustent
depuis longtemps concernant les packages d'openbsd.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de
gain en taille par rapport à gzip, du bon pour les cdroms et la bp
des ftps).
- Pourquoi les messages d'erreur de pkg_add sont ils affichés sur
STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand
l'installation à échouée ?).
Le Mon, 17 May 2004 21:29:31 +0000 (UTC), Marc Espie écrivais:
Bref, pas mal de boulot en perspective, mais c'est en cours...
Je saute sur l'occasion pour poser des questions qui me tarabustent depuis longtemps concernant les packages d'openbsd.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps). - Pourquoi les messages d'erreur de pkg_add sont ils affichés sur STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand l'installation à échouée ?).
Miod Vallat
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de
gain en taille par rapport à gzip, du bon pour les cdroms et la bp
des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain
nombre d'architectures dites «obsolètes», alors que les performances de
gzip restent tolérables.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
espie
In article <40ab5342$0$30075$, Miod Vallat wrote:
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire a la decompression (tampons plus gros que gzip).
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
In article <40ab5342$0$30075$636a15ce@news.free.fr>,
Miod Vallat <miod@online.fr> wrote:
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de
gain en taille par rapport à gzip, du bon pour les cdroms et la bp
des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain
nombre d'architectures dites «obsolètes», alors que les performances de
gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire
a la decompression (tampons plus gros que gzip).
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
- Pourquoi les packages ne sont pas compréssés avec bzip2 (~ 10% de gain en taille par rapport à gzip, du bon pour les cdroms et la bp des ftps).
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire a la decompression (tampons plus gros que gzip).
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
espie
In article , Benjamin Pineau wrote:
- Pourquoi les messages d'erreur de pkg_add sont ils affichés sur STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand l'installation à échouée ?).
Le code de reprise sur erreur est encore loin d'etre parfait. Le cahier des charges initial, c'etait de faire aussi bien que les vieux outils. Les nouveaux outils font en fait mieux, puisqu'ils detectent plein de problemes possibles avant meme de commencer a installer le package, mais il reste des petits details a uniformiser...
C'est sur ma liste de trucs a faire.
In article <slrncami7v.215i.ben@tosh.zouh.org>,
Benjamin Pineau <nospouet-ben@zouh.org-nospam.com> wrote:
- Pourquoi les messages d'erreur de pkg_add sont ils affichés sur
STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand
l'installation à échouée ?).
Le code de reprise sur erreur est encore loin d'etre parfait. Le cahier
des charges initial, c'etait de faire aussi bien que les vieux outils.
Les nouveaux outils font en fait mieux, puisqu'ils detectent plein de
problemes possibles avant meme de commencer a installer le package,
mais il reste des petits details a uniformiser...
- Pourquoi les messages d'erreur de pkg_add sont ils affichés sur STDOUT et non STDERR ? (et pourquoi retourne-t-il 0 même quand l'installation à échouée ?).
Le code de reprise sur erreur est encore loin d'etre parfait. Le cahier des charges initial, c'etait de faire aussi bien que les vieux outils. Les nouveaux outils font en fait mieux, puisqu'ils detectent plein de problemes possibles avant meme de commencer a installer le package, mais il reste des petits details a uniformiser...
C'est sur ma liste de trucs a faire.
Miod Vallat
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire a la decompression (tampons plus gros que gzip).
Ceci n'est pas le problème le plus important, puisque la quantité de mémoire nécessaire à la compression comme à la décompression est bornée et connue à l'avance.
Bon, bien entendu, quand on veut pouvoir tourner dans 8MB ou 12MB sur certaines architectures, c'est loupé. D'un autre côté, il faut vraiment n'avoir rien d'intéressant à faire dans sa vie pour se crever le cul avec (strictement) moins de 16MB de mémoire.
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
Ah, oui, les paquetages arlésiens, euh, je veux dire, les paquetages gras, c'est bien ça ?
Parce que bzip2 coûte très, très, très très très cher sur un certain
nombre d'architectures dites «obsolètes», alors que les performances de
gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire
a la decompression (tampons plus gros que gzip).
Ceci n'est pas le problème le plus important, puisque la quantité de
mémoire nécessaire à la compression comme à la décompression est bornée
et connue à l'avance.
Bon, bien entendu, quand on veut pouvoir tourner dans 8MB ou 12MB sur
certaines architectures, c'est loupé. D'un autre côté, il faut vraiment
n'avoir rien d'intéressant à faire dans sa vie pour se crever le cul
avec (strictement) moins de 16MB de mémoire.
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
Ah, oui, les paquetages arlésiens, euh, je veux dire, les paquetages
gras, c'est bien ça ?
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Mais aussi parce que bzip2 consomme de toutes facons pas mal de memoire a la decompression (tampons plus gros que gzip).
Ceci n'est pas le problème le plus important, puisque la quantité de mémoire nécessaire à la compression comme à la décompression est bornée et connue à l'avance.
Bon, bien entendu, quand on veut pouvoir tourner dans 8MB ou 12MB sur certaines architectures, c'est loupé. D'un autre côté, il faut vraiment n'avoir rien d'intéressant à faire dans sa vie pour se crever le cul avec (strictement) moins de 16MB de mémoire.
Pour ce qui est de gagner de la place sur les CD, on a d'autres plans.
Ah, oui, les paquetages arlésiens, euh, je veux dire, les paquetages gras, c'est bien ça ?
Benjamin Pineau
Le 19 May 2004 12:29:54 GMT, Miod Vallat écrivais:
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Ok, intéressant à savoir, cochon de bzip2 ;) (ps: de quelles archis s' agit-il ?).
Ah, et j'imagine que les packages doivent impérativement être compréssés avec le même algo sur toutes les archis ?
Le 19 May 2004 12:29:54 GMT,
Miod Vallat <miod@online.fr> écrivais:
Parce que bzip2 coûte très, très, très très très cher sur un certain
nombre d'architectures dites «obsolètes», alors que les performances de
gzip restent tolérables.
Ok, intéressant à savoir, cochon de bzip2 ;) (ps: de quelles archis s'
agit-il ?).
Ah, et j'imagine que les packages doivent impérativement être compréssés
avec le même algo sur toutes les archis ?
Le 19 May 2004 12:29:54 GMT, Miod Vallat écrivais:
Parce que bzip2 coûte très, très, très très très cher sur un certain nombre d'architectures dites «obsolètes», alors que les performances de gzip restent tolérables.
Ok, intéressant à savoir, cochon de bzip2 ;) (ps: de quelles archis s' agit-il ?).
Ah, et j'imagine que les packages doivent impérativement être compréssés avec le même algo sur toutes les archis ?