Sous OpenBSD-3.5, j'ai mis un « MANZ = yes » dans mon /etc/mk.conf.
Lorsque je fais un make build, ça fonctionne bien. En revanche, il y a
des ports qui ne fonctionnent pas avec ça :
# make install
===> Building package for colorls-3.5
Creating package /usr/ports/packages/i386/all/colorls-3.5.tgz
can't open /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386//usr/local/man/man1/colorls.0: No such file or directory at /usr/libdata/perl5/OpenBSD/md5.pm line 35.
===> Cleaning for colorls-3.5
rm -f /usr/ports/packages/i386/all/colorls-3.5.tgz
*** Error code 1
Stop in /usr/ports/sysutils/colorls (line 1798 of /usr/ports/infrastructure/mk/bsd.port.mk).
*** Error code 1
Stop in /usr/ports/sysutils/colorls (line 1116 of /usr/ports/infrastructure/mk/bsd.port.mk).
Si j'ai bien compris l'affaire, pkg_create est appelé avec un « -f
pkg/PLIST » et échoue (sur le md5) car le fichier man/man1/colorls.0
s'appelle en fait man/man1/colorls.0.gz dans mon cas.
Donc, que faire pour que ça fonctionne correctement (et surtout
proprement) :
- ne pas utiliser MANZ
- définir PKG_ARGS
- virer les pages man de pkg/PLIST
- autre
?
- ne pas utiliser MANZ Oui. Ca n'est pas supporte. Pas mentionne du tout dans bsd.port.mk.
D'ailleurs, si ca `presque marche' pour un des ports, c'est parce qu'exceptionnellement il utilise bsd.man.mk...
Benoit Izac
Bonjour,
le 24/05/2004 à 07:44, Marc Espie a écrit dans le message <c8s22v$1t1t$ :
- ne pas utiliser MANZ
Oui. Ca n'est pas supporte. Pas mentionne du tout dans bsd.port.mk. D'ailleurs, si ca `presque marche' pour un des ports, c'est parce qu'exceptionnellement il utilise bsd.man.mk...
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête à confusion.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages de manuel et les différents *.mk.
De plus MANZ est bien utilisé à un moment : # make package | grep gzip gzip -cf colorls.cat1 > /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
-- Benoit Izac
Bonjour,
le 24/05/2004 à 07:44, Marc Espie a écrit
dans le message <c8s22v$1t1t$1@biggoron.nerim.net> :
- ne pas utiliser MANZ
Oui. Ca n'est pas supporte. Pas mentionne du tout dans bsd.port.mk.
D'ailleurs, si ca `presque marche' pour un des ports, c'est parce
qu'exceptionnellement il utilise bsd.man.mk...
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête
à confusion.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand
même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages
de manuel et les différents *.mk.
De plus MANZ est bien utilisé à un moment :
# make package | grep gzip
gzip -cf colorls.cat1 > /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz
Même si ça ne me dérange pas d'utiliser des pages de manuel non
compressées (j'ai de la place), reconnais qu'il y a un problème avec
MANZ.
le 24/05/2004 à 07:44, Marc Espie a écrit dans le message <c8s22v$1t1t$ :
- ne pas utiliser MANZ
Oui. Ca n'est pas supporte. Pas mentionne du tout dans bsd.port.mk. D'ailleurs, si ca `presque marche' pour un des ports, c'est parce qu'exceptionnellement il utilise bsd.man.mk...
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête à confusion.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages de manuel et les différents *.mk.
De plus MANZ est bien utilisé à un moment : # make package | grep gzip gzip -cf colorls.cat1 > /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
-- Benoit Izac
espie
In article , Benoit Izac wrote:
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
Ca se discute... pas clair qu'avoir deux fichiers de conf separes se justifie.
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête à confusion. Eh bien, envoie un patch.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages de manuel et les différents *.mk.
Tout le monde sauf toi s'en sort... la-encore, c'est pas facile d'ameliorer la doc. Vas-y, envoie des patchs.
De plus MANZ est bien utilisé à un moment : # make package | grep gzip gzip -cf colorls.cat1 > /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz Je n'ai pas dit le contraire. J'ai juste dit que ce n'etait pas le fait de
bsd.port.mk. Comme par hasard, colorls est un des tres rares ports de trucs `pure bsd', qui donc utilise le reste de l'infrastructure dans /usr/share/mk.
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
Non, il y a un bug dans le port de colorls.
In article <87aczyaue1@message.id>, Benoit Izac <benoit.izac@free.fr> wrote:
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
Ca se discute... pas clair qu'avoir deux fichiers de conf separes se
justifie.
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête
à confusion.
Eh bien, envoie un patch.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand
même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages
de manuel et les différents *.mk.
Tout le monde sauf toi s'en sort... la-encore, c'est pas facile d'ameliorer
la doc. Vas-y, envoie des patchs.
De plus MANZ est bien utilisé à un moment :
# make package | grep gzip
gzip -cf colorls.cat1 >
/usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz
Je n'ai pas dit le contraire. J'ai juste dit que ce n'etait pas le fait de
bsd.port.mk. Comme par hasard, colorls est un des tres rares ports de trucs
`pure bsd', qui donc utilise le reste de l'infrastructure dans
/usr/share/mk.
Même si ça ne me dérange pas d'utiliser des pages de manuel non
compressées (j'ai de la place), reconnais qu'il y a un problème avec
MANZ.
Justement, ne devraient-ils (les ports) pas utiliser ce fichier ?
Ca se discute... pas clair qu'avoir deux fichiers de conf separes se justifie.
En tout cas, la lecture de mk.conf(5) et /usr/share/mk/bsd.own.mk prête à confusion. Eh bien, envoie un patch.
Même si je reconnais que bsd.port.mk(5) ne liste pas MANZ, c'est quand même pas pratique de se faire un mk.conf en jonglant entre ces 2 pages de manuel et les différents *.mk.
Tout le monde sauf toi s'en sort... la-encore, c'est pas facile d'ameliorer la doc. Vas-y, envoie des patchs.
De plus MANZ est bien utilisé à un moment : # make package | grep gzip gzip -cf colorls.cat1 > /usr/ports/sysutils/colorls/w-colorls-3.5/fake-i386/usr/local/man/man1/colorls.0.gz Je n'ai pas dit le contraire. J'ai juste dit que ce n'etait pas le fait de
bsd.port.mk. Comme par hasard, colorls est un des tres rares ports de trucs `pure bsd', qui donc utilise le reste de l'infrastructure dans /usr/share/mk.
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
Non, il y a un bug dans le port de colorls.
Benoit Izac
Bonjour,
le 25/05/2004 à 17:33, Marc Espie a écrit dans le message <c8vovn$19ac$ :
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
Non, il y a un bug dans le port de colorls.
Et aussi dans graphic/png.
Tout ceci n'est pas très logique. MANZ ne doit pas être pris en compte dans les ports ; certains ports utilisent <bsd.man.mk> alors qu'ils ne devraient pas; donc on retire MANZ pour que ça marche.
J'imagine que ce n'est pas la peine que je fasse un rapport de bug pour ça. J'avais d'ailleurs écrit au mainteneur de png (le 18 mai) et, à ce jour, je n'ai toujours pas eu de réponse.
Quand à mes patchs pour la documentation, je ne vois pas ce que je pourrais modifier puisqu'elle est correcte.
-- Benoit Izac
Bonjour,
le 25/05/2004 à 17:33, Marc Espie a écrit
dans le message <c8vovn$19ac$1@biggoron.nerim.net> :
Même si ça ne me dérange pas d'utiliser des pages de manuel non
compressées (j'ai de la place), reconnais qu'il y a un problème avec
MANZ.
Non, il y a un bug dans le port de colorls.
Et aussi dans graphic/png.
Tout ceci n'est pas très logique. MANZ ne doit pas être pris en compte
dans les ports ; certains ports utilisent <bsd.man.mk> alors qu'ils ne
devraient pas; donc on retire MANZ pour que ça marche.
J'imagine que ce n'est pas la peine que je fasse un rapport de bug pour
ça. J'avais d'ailleurs écrit au mainteneur de png (le 18 mai) et, à ce
jour, je n'ai toujours pas eu de réponse.
Quand à mes patchs pour la documentation, je ne vois pas ce que je
pourrais modifier puisqu'elle est correcte.
le 25/05/2004 à 17:33, Marc Espie a écrit dans le message <c8vovn$19ac$ :
Même si ça ne me dérange pas d'utiliser des pages de manuel non compressées (j'ai de la place), reconnais qu'il y a un problème avec MANZ.
Non, il y a un bug dans le port de colorls.
Et aussi dans graphic/png.
Tout ceci n'est pas très logique. MANZ ne doit pas être pris en compte dans les ports ; certains ports utilisent <bsd.man.mk> alors qu'ils ne devraient pas; donc on retire MANZ pour que ça marche.
J'imagine que ce n'est pas la peine que je fasse un rapport de bug pour ça. J'avais d'ailleurs écrit au mainteneur de png (le 18 mai) et, à ce jour, je n'ai toujours pas eu de réponse.
Quand à mes patchs pour la documentation, je ne vois pas ce que je pourrais modifier puisqu'elle est correcte.
