maintenant que les paquetages netbsd ont plus ou moins un numéro de
version à trois chiffres, ne serait-il pas envisageable de simplifier
la procédure d'upgrade ? Si A dépend de B et que B passe de la version
1.1.1 à 1.1.2 par exemple, je pense qu'il ne sera jamais nécessaire de
recompiler A car l'ABI de B n'est pas modifiée.
Une question plus générale : comment peut-on faire pour détecter une
mise à jour qui va faire passer une bibliothèque partagée à une
version majeure supérieure (par exemple libchose.so.2 à libchose.so.3)
ce qui rend obligatoire la recompilation de tous les paquetages
dépendants, du cas où la bibliothèque reste en place ? Peut-on
automatiser ces opérations ?
Et dans le cas où A dépend de B et B dépend de C, si C doit être mis à
jour, est il obligatoire de recompiler A ? Visiblement c'est souvent
le cas, mais pourquoi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Manuel Bouyer
Cyrille Szymanski wrote:
Bonjour,
quelques questions de néophyte :
maintenant que les paquetages netbsd ont plus ou moins un numéro de version à trois chiffres, ne serait-il pas envisageable de simplifier
C'est pas le cas de tout les packages. En fait ca depend, le numero de version du package est celui d'origine, donc ca depend comment l'auteur a goupille son truc.
la procédure d'upgrade ? Si A dépend de B et que B passe de la version 1.1.1 à 1.1.2 par exemple, je pense qu'il ne sera jamais nécessaire de recompiler A car l'ABI de B n'est pas modifiée.
Ca depend si l'auteur do soft fait les trucs proprement ou pas. C'est aussi pour ca que les dependances ne sont pas strictes, mais sont des >=.
Une question plus générale : comment peut-on faire pour détecter une mise à jour qui va faire passer une bibliothèque partagée à une version majeure supérieure (par exemple libchose.so.2 à libchose.so.3) ce qui rend obligatoire la recompilation de tous les paquetages dépendants, du cas où la bibliothèque reste en place ? Peut-on
Heu ... regarder dans PLIST ?
automatiser ces opérations ?
make update doit faire ce qu'il faut.
Et dans le cas où A dépend de B et B dépend de C, si C doit être mis à jour, est il obligatoire de recompiler A ? Visiblement c'est souvent le cas, mais pourquoi ?
Parce que souvent, dans le cas des librairies, il y a des includes de C utilises (directement ou indirectement) dans A
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Cyrille Szymanski <cns2@cns.invalid> wrote:
Bonjour,
quelques questions de néophyte :
maintenant que les paquetages netbsd ont plus ou moins un numéro de
version à trois chiffres, ne serait-il pas envisageable de simplifier
C'est pas le cas de tout les packages. En fait ca depend, le numero de
version du package est celui d'origine, donc ca depend comment l'auteur
a goupille son truc.
la procédure d'upgrade ? Si A dépend de B et que B passe de la version
1.1.1 à 1.1.2 par exemple, je pense qu'il ne sera jamais nécessaire de
recompiler A car l'ABI de B n'est pas modifiée.
Ca depend si l'auteur do soft fait les trucs proprement ou pas.
C'est aussi pour ca que les dependances ne sont pas strictes, mais sont
des >=.
Une question plus générale : comment peut-on faire pour détecter une
mise à jour qui va faire passer une bibliothèque partagée à une
version majeure supérieure (par exemple libchose.so.2 à libchose.so.3)
ce qui rend obligatoire la recompilation de tous les paquetages
dépendants, du cas où la bibliothèque reste en place ? Peut-on
Heu ... regarder dans PLIST ?
automatiser ces opérations ?
make update doit faire ce qu'il faut.
Et dans le cas où A dépend de B et B dépend de C, si C doit être mis à
jour, est il obligatoire de recompiler A ? Visiblement c'est souvent
le cas, mais pourquoi ?
Parce que souvent, dans le cas des librairies, il y a des includes de C
utilises (directement ou indirectement) dans A
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
maintenant que les paquetages netbsd ont plus ou moins un numéro de version à trois chiffres, ne serait-il pas envisageable de simplifier
C'est pas le cas de tout les packages. En fait ca depend, le numero de version du package est celui d'origine, donc ca depend comment l'auteur a goupille son truc.
la procédure d'upgrade ? Si A dépend de B et que B passe de la version 1.1.1 à 1.1.2 par exemple, je pense qu'il ne sera jamais nécessaire de recompiler A car l'ABI de B n'est pas modifiée.
Ca depend si l'auteur do soft fait les trucs proprement ou pas. C'est aussi pour ca que les dependances ne sont pas strictes, mais sont des >=.
Une question plus générale : comment peut-on faire pour détecter une mise à jour qui va faire passer une bibliothèque partagée à une version majeure supérieure (par exemple libchose.so.2 à libchose.so.3) ce qui rend obligatoire la recompilation de tous les paquetages dépendants, du cas où la bibliothèque reste en place ? Peut-on
Heu ... regarder dans PLIST ?
automatiser ces opérations ?
make update doit faire ce qu'il faut.
Et dans le cas où A dépend de B et B dépend de C, si C doit être mis à jour, est il obligatoire de recompiler A ? Visiblement c'est souvent le cas, mais pourquoi ?
Parce que souvent, dans le cas des librairies, il y a des includes de C utilises (directement ou indirectement) dans A
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Cyrille Szymanski
Le 04-10-2004, Manuel Bouyer a écrit :
make update doit faire ce qu'il faut.
make update est bien barbare je trouve. Pour une machine qui n'a que quelques packages c'est bon, sur ma machine de bureau qui en compte 200 ça fait déjà beaucoup plus mal. Surtout si on s'y prend mal.
De plus, que ce soit make update ou make replace, ça me supprime les anciennes bibliothèques partagées. Tel que je vois les choses, si l'ancienne es replacée in situ par une nouvelle il y a des chances pour que les packages qui en dépendent fonctionnent encore. Si une nouvelle version est installée pourquoi ne pas la laisser ? Les anciens packages l'utiliseront et les nouveaux seront liés à la nouvelle version, non ?
-- cns
Le 04-10-2004, Manuel Bouyer <bouyer@nerim.net> a écrit :
make update doit faire ce qu'il faut.
make update est bien barbare je trouve. Pour une machine qui n'a que
quelques packages c'est bon, sur ma machine de bureau qui en compte
200 ça fait déjà beaucoup plus mal. Surtout si on s'y prend mal.
De plus, que ce soit make update ou make replace, ça me supprime les
anciennes bibliothèques partagées. Tel que je vois les choses, si
l'ancienne es replacée in situ par une nouvelle il y a des chances
pour que les packages qui en dépendent fonctionnent encore. Si une
nouvelle version est installée pourquoi ne pas la laisser ? Les
anciens packages l'utiliseront et les nouveaux seront liés à la
nouvelle version, non ?
make update est bien barbare je trouve. Pour une machine qui n'a que quelques packages c'est bon, sur ma machine de bureau qui en compte 200 ça fait déjà beaucoup plus mal. Surtout si on s'y prend mal.
De plus, que ce soit make update ou make replace, ça me supprime les anciennes bibliothèques partagées. Tel que je vois les choses, si l'ancienne es replacée in situ par une nouvelle il y a des chances pour que les packages qui en dépendent fonctionnent encore. Si une nouvelle version est installée pourquoi ne pas la laisser ? Les anciens packages l'utiliseront et les nouveaux seront liés à la nouvelle version, non ?
-- cns
Manuel Bouyer
Cyrille Szymanski wrote:
De plus, que ce soit make update ou make replace, ça me supprime les anciennes bibliothèques partagées. Tel que je vois les choses, si l'ancienne es replacée in situ par une nouvelle il y a des chances pour que les packages qui en dépendent fonctionnent encore. Si une nouvelle version est installée pourquoi ne pas la laisser ? Les anciens packages l'utiliseront et les nouveaux seront liés à la nouvelle version, non ?
Oui, mais il faut que quelque chose se rapelle qu'elle est encore la, et il n'y a pas l'infrastructure dans les pkg_* pour ca. Les pkg_view devraient resoudre ca de maniere plus generique.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Cyrille Szymanski <cns2@cns.invalid> wrote:
De plus, que ce soit make update ou make replace, ça me supprime les
anciennes bibliothèques partagées. Tel que je vois les choses, si
l'ancienne es replacée in situ par une nouvelle il y a des chances
pour que les packages qui en dépendent fonctionnent encore. Si une
nouvelle version est installée pourquoi ne pas la laisser ? Les
anciens packages l'utiliseront et les nouveaux seront liés à la
nouvelle version, non ?
Oui, mais il faut que quelque chose se rapelle qu'elle est encore la,
et il n'y a pas l'infrastructure dans les pkg_* pour ca.
Les pkg_view devraient resoudre ca de maniere plus generique.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
De plus, que ce soit make update ou make replace, ça me supprime les anciennes bibliothèques partagées. Tel que je vois les choses, si l'ancienne es replacée in situ par une nouvelle il y a des chances pour que les packages qui en dépendent fonctionnent encore. Si une nouvelle version est installée pourquoi ne pas la laisser ? Les anciens packages l'utiliseront et les nouveaux seront liés à la nouvelle version, non ?
Oui, mais il faut que quelque chose se rapelle qu'elle est encore la, et il n'y a pas l'infrastructure dans les pkg_* pour ca. Les pkg_view devraient resoudre ca de maniere plus generique.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
