Afin de faire en sorte que de maîtriser au mieux l'environnement d'un
paquet (au format natif, à usage personnel), j'ai utilisé dans le
fichier control des dépendances comme :
... c'est à dire sur une version particulière, jusqu'à sa révision
Debian. Je m'aperçois que mon paquet une fois compilé présente les
règles suivantes ;
- Comment est-ce que la compilation de mon paquet a transformé ma
dépendance stricte sur libpcap0.8-dev en une dépendance plus souple
sur libpcap0.8 ?
- Quelle est la bonne attitude à adopter afin de s'assurer une
reproductibilité maximale dans la génération d'un paquet ?
Merci.
--
Nul vent n'est favorable à celui qui ne sait pas où il va
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20111107084947.GA3183@david-pc.nexcom.bzh
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
Rémi Vanicat
David Soulayrol writes:
Bonjour,
Afin de faire en sorte que de maîtriser au mieux l'environnement d'un paquet (au format natif, à usage personnel), j'ai utilisé dans le fichier control des dépendances comme :
... c'est à dire sur une version particulière, jusqu'à sa révision Debian. Je m'aperçois que mon paquet une fois compilé présente les règles suivantes ;
- Comment est-ce que la compilation de mon paquet a transformé ma dépendance stricte sur libpcap0.8-dev en une dépendance plus souple sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
- Quelle est la bonne attitude à adopter afin de s'assurer une reproductibilité maximale dans la génération d'un paquet ?
je ne suis pas sur que ce soit nécessaire, mais la puild-dépendances « forte » sur le paquet dev permet de s'assurer que le paquets ne sera pas construit avec une autre version de libpcap.
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
David Soulayrol <david.soulayrol@gmail.com> writes:
Bonjour,
Afin de faire en sorte que de maîtriser au mieux l'environnement d'un
paquet (au format natif, à usage personnel), j'ai utilisé dans le
fichier control des dépendances comme :
... c'est à dire sur une version particulière, jusqu'à sa révision
Debian. Je m'aperçois que mon paquet une fois compilé présente les
règles suivantes ;
- Comment est-ce que la compilation de mon paquet a transformé ma
dépendance stricte sur libpcap0.8-dev en une dépendance plus souple
sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers
binaires générés. Le système de génération des dépendances à
déterminer que l'exécutable pouvait tourné avec n'importe quel version
de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
- Quelle est la bonne attitude à adopter afin de s'assurer une
reproductibilité maximale dans la génération d'un paquet ?
je ne suis pas sur que ce soit nécessaire, mais la puild-dépendances
« forte » sur le paquet dev permet de s'assurer que le paquets ne sera
pas construit avec une autre version de libpcap.
Perso, si je voulais être sur de construire le même paquet, je
construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du
genre) que je conserverais ensuite dans un coin.
--
Rémi Vanicat
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/8739e0z3m3.dlv@debian.org
Afin de faire en sorte que de maîtriser au mieux l'environnement d'un paquet (au format natif, à usage personnel), j'ai utilisé dans le fichier control des dépendances comme :
... c'est à dire sur une version particulière, jusqu'à sa révision Debian. Je m'aperçois que mon paquet une fois compilé présente les règles suivantes ;
- Comment est-ce que la compilation de mon paquet a transformé ma dépendance stricte sur libpcap0.8-dev en une dépendance plus souple sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
- Quelle est la bonne attitude à adopter afin de s'assurer une reproductibilité maximale dans la génération d'un paquet ?
je ne suis pas sur que ce soit nécessaire, mais la puild-dépendances « forte » sur le paquet dev permet de s'assurer que le paquets ne sera pas construit avec une autre version de libpcap.
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
David Soulayrol
On 2011.11.07 10:25:08 +0100, Rémi Vanicat wrote:
> Je me pose donc les questions suivantes ; > > - Comment est-ce que la compilation de mon paquet a transformé ma > dépendance stricte sur libpcap0.8-dev en une dépendance plus souple > sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la les dépendances sont déduites des Build-Depends fournies ?
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et propre. Mais même en complément de cette solution, je pense qu'il est bon d'apporter un maximum de contraintes aux paquets sources afin d'éviter la génération hasardeuse de paquets binaires en dehors de la plate-forme dédiée. J'hésite cependant encore sur le niveau de fermeté à apporter aux Build-Depends.
-- Les arbres sont responsables de plus de pollution aérienne que les usines. -+- Ronald Reagan -+-
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On 2011.11.07 10:25:08 +0100, Rémi Vanicat wrote:
> Je me pose donc les questions suivantes ;
>
> - Comment est-ce que la compilation de mon paquet a transformé ma
> dépendance stricte sur libpcap0.8-dev en une dépendance plus souple
> sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers
binaires générés. Le système de génération des dépendances à
déterminer que l'exécutable pouvait tourné avec n'importe quel version
de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la
les dépendances sont déduites des Build-Depends fournies ?
Perso, si je voulais être sur de construire le même paquet, je
construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du
genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et
propre. Mais même en complément de cette solution, je pense qu'il est
bon d'apporter un maximum de contraintes aux paquets sources afin
d'éviter la génération hasardeuse de paquets binaires en dehors de la
plate-forme dédiée. J'hésite cependant encore sur le niveau de fermeté à
apporter aux Build-Depends.
--
Les arbres sont responsables de plus de pollution aérienne que les
usines.
-+- Ronald Reagan -+-
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20111108141814.GH3183@david-pc.nexcom.bzh
> Je me pose donc les questions suivantes ; > > - Comment est-ce que la compilation de mon paquet a transformé ma > dépendance stricte sur libpcap0.8-dev en une dépendance plus souple > sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la les dépendances sont déduites des Build-Depends fournies ?
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et propre. Mais même en complément de cette solution, je pense qu'il est bon d'apporter un maximum de contraintes aux paquets sources afin d'éviter la génération hasardeuse de paquets binaires en dehors de la plate-forme dédiée. J'hésite cependant encore sur le niveau de fermeté à apporter aux Build-Depends.
-- Les arbres sont responsables de plus de pollution aérienne que les usines. -+- Ronald Reagan -+-
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Rémi Vanicat
David Soulayrol writes:
On 2011.11.07 10:25:08 +0100, Rémi Vanicat wrote:
> Je me pose donc les questions suivantes ; > > - Comment est-ce que la compilation de mon paquet a transformé ma > dépendance stricte sur libpcap0.8-dev en une dépendance plus souple > sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la les dépendances sont déduites des Build-Depends fournies ?
Elles ne sont pas déduite des Build-Depends, mais des fichiers se trouvant dans le paquet binaire. C'est dpkg-shlibdeps qui fait ça, en lisant sa documentation tu trouveras peut-être ta réponse.
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et propre. Mais même en complément de cette solution, je pense qu'il est bon d'apporter un maximum de contraintes aux paquets sources afin d'éviter la génération hasardeuse de paquets binaires en dehors de la plate-forme dédiée.
Je pratique la fabrication de paquets officiels, pour les quels, au contraire, il faut mettre de dépendance les plus souples possibles. Ça permet de pouvoir adapter un paquet aux changements de la plate-forme en se contentant de recompiler le paquet.
C'est d'autant plus important que avec l'évolution de unstable (les paquets étant construit là avant de migrer par étapes jusqu'à la stable) les versions des paquets disponible au moment de la compilation risque d'avoir disparu entre temps. -- Rémi Vanicat
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
David Soulayrol <david.soulayrol@gmail.com> writes:
On 2011.11.07 10:25:08 +0100, Rémi Vanicat wrote:
> Je me pose donc les questions suivantes ;
>
> - Comment est-ce que la compilation de mon paquet a transformé ma
> dépendance stricte sur libpcap0.8-dev en une dépendance plus souple
> sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers
binaires générés. Le système de génération des dépendances à
déterminer que l'exécutable pouvait tourné avec n'importe quel version
de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la
les dépendances sont déduites des Build-Depends fournies ?
Elles ne sont pas déduite des Build-Depends, mais des fichiers se
trouvant dans le paquet binaire. C'est dpkg-shlibdeps qui fait ça, en
lisant sa documentation tu trouveras peut-être ta réponse.
Perso, si je voulais être sur de construire le même paquet, je
construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du
genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et
propre. Mais même en complément de cette solution, je pense qu'il est
bon d'apporter un maximum de contraintes aux paquets sources afin
d'éviter la génération hasardeuse de paquets binaires en dehors de la
plate-forme dédiée.
Je pratique la fabrication de paquets officiels, pour les quels, au
contraire, il faut mettre de dépendance les plus souples possibles. Ça
permet de pouvoir adapter un paquet aux changements de la plate-forme en se
contentant de recompiler le paquet.
C'est d'autant plus important que avec l'évolution de unstable (les
paquets étant construit là avant de migrer par étapes jusqu'à la stable)
les versions des paquets disponible au moment de la compilation risque
d'avoir disparu entre temps.
--
Rémi Vanicat
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/87y5vqxxbk.dlv@debian.org
> Je me pose donc les questions suivantes ; > > - Comment est-ce que la compilation de mon paquet a transformé ma > dépendance stricte sur libpcap0.8-dev en une dépendance plus souple > sur libpcap0.8 ?
Les build depend et les dépend ne sont pas strictement lié.
- les depends sont généré automatiquement à partir des fichiers binaires générés. Le système de génération des dépendances à déterminer que l'exécutable pouvait tourné avec n'importe quel version de libpcap0.8 supérieur à 1.0.0, c'est donc sûrement vraie.
Cela fait sens. Est-ce qu'il y a moyen de déterminer comment la les dépendances sont déduites des Build-Depends fournies ?
Elles ne sont pas déduite des Build-Depends, mais des fichiers se trouvant dans le paquet binaire. C'est dpkg-shlibdeps qui fait ça, en lisant sa documentation tu trouveras peut-être ta réponse.
Perso, si je voulais être sur de construire le même paquet, je construirais un chroot (avec pbuilder, cowbuilder... ou quelque chose du genre) que je conserverais ensuite dans un coin.
C'est effectivement sans doute la solution la plus pérenne et propre. Mais même en complément de cette solution, je pense qu'il est bon d'apporter un maximum de contraintes aux paquets sources afin d'éviter la génération hasardeuse de paquets binaires en dehors de la plate-forme dédiée.
Je pratique la fabrication de paquets officiels, pour les quels, au contraire, il faut mettre de dépendance les plus souples possibles. Ça permet de pouvoir adapter un paquet aux changements de la plate-forme en se contentant de recompiler le paquet.
C'est d'autant plus important que avec l'évolution de unstable (les paquets étant construit là avant de migrer par étapes jusqu'à la stable) les versions des paquets disponible au moment de la compilation risque d'avoir disparu entre temps. -- Rémi Vanicat
