Bug#634741: debhelper: Undesirable dir.gz autogeneration
Samuel Thibault wrote: FYI in latest versions of automake, if you set AM_UPDATE_INFO_DIR=no in the environment it will suppress creating the dir file. If debhelper just set that it would solve the problem. Reopening the bug and retitling it. debhelper does not contain any explicit support for automake. It does not run automake for you, so it cannot set any variables when automake is being run. Can that be set at make install time or at configure time? -- see shy jo signature.asc Description: Digital signature
Bug#634741: debhelper: Undesirable dir.gz autogeneration
* Joey Hess (jo...@debian.org) wrote: Samuel Thibault wrote: FYI in latest versions of automake, if you set AM_UPDATE_INFO_DIR=no in the environment it will suppress creating the dir file. If debhelper just set that it would solve the problem. Reopening the bug and retitling it. debhelper does not contain any explicit support for automake. It does not run automake for you, so it cannot set any variables when automake is being run. Can that be set at make install time or at configure time? Sorry Joey I should have been clearer. Setting this at make install time should have the right effect. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#634741: debhelper: Undesirable dir.gz autogeneration
* Eric Dorland (e...@debian.org) wrote: * Samuel Thibault (sthiba...@debian.org) wrote: Joey Hess, le Tue 19 Jul 2011 17:54:06 -0400, a écrit : Samuel Thibault wrote: produces a package with a /usr/share/info/dir.gz. Shouldn't debhelper be able to drop dir? For now, the solution we have found is to tell dh_auto_install to install in debian/tmp, and create a debian/install which contains all the desired directories, which is tedious. Or another solution would be to remove the file explicitly after dh_auto_install, but dh_auto_install could as well just do it itself, to avoid the same tedious thing for all simple packages which have a texinfo documentation. dh_auto_install is just a generic way to run make install, it's not appropriate for it to go in and try to override the installation sequence. dh_install -X could be used, In the case at stake, no, because it's a single-binary package, so everything is already installed. One thus has to pass --destdir to dh_auto_install, and then use dh_install by hand, it's a bit tedious. or you could fix the Makefile to not install it It's an automake Makefile, I don't really want to patch that :) (why should an arbitrary make install overwrite /usr/share/info/dir.gz?), It doesn't overwrites it, it updates it. make install is originally intended to install in the real place ;) or possibly fix texinfo to not create it when building documentation. That could be an option. Cc-ing automake: in the case DESTDIR is not empty, automake should perhaps prevent the dir.gz update. FYI in latest versions of automake, if you set AM_UPDATE_INFO_DIR=no in the environment it will suppress creating the dir file. If debhelper just set that it would solve the problem. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#634741: debhelper: Undesirable dir.gz autogeneration
reopen 634741 retitle 634741 debhelper: please set AM_UPDATE_INFO_DIR to no thanks Eric Dorland, le Sun 05 Feb 2012 01:12:16 -0500, a écrit : * Samuel Thibault (sthiba...@debian.org) wrote: Joey Hess, le Tue 19 Jul 2011 17:54:06 -0400, a écrit : Samuel Thibault wrote: produces a package with a /usr/share/info/dir.gz. Shouldn't debhelper be able to drop dir? For now, the solution we have found is to tell dh_auto_install to install in debian/tmp, and create a debian/install which contains all the desired directories, which is tedious. Or another solution would be to remove the file explicitly after dh_auto_install, but dh_auto_install could as well just do it itself, to avoid the same tedious thing for all simple packages which have a texinfo documentation. dh_auto_install is just a generic way to run make install, it's not appropriate for it to go in and try to override the installation sequence. dh_install -X could be used, In the case at stake, no, because it's a single-binary package, so everything is already installed. One thus has to pass --destdir to dh_auto_install, and then use dh_install by hand, it's a bit tedious. or you could fix the Makefile to not install it It's an automake Makefile, I don't really want to patch that :) (why should an arbitrary make install overwrite /usr/share/info/dir.gz?), It doesn't overwrites it, it updates it. make install is originally intended to install in the real place ;) or possibly fix texinfo to not create it when building documentation. That could be an option. Cc-ing automake: in the case DESTDIR is not empty, automake should perhaps prevent the dir.gz update. FYI in latest versions of automake, if you set AM_UPDATE_INFO_DIR=no in the environment it will suppress creating the dir file. If debhelper just set that it would solve the problem. Reopening the bug and retitling it. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634741: debhelper: Undesirable dir.gz autogeneration
Package: debhelper Version: 8.9.2 Severity: normal Hi, I'm preparing a package which contains one single binary and some texinfo documentation. But when I do dpkg-buildpackage, a debian/package/usr/share/info/dir.gz is automatically generated. lintian doesn't like at all. In other words, it complains with the presence of dir.gz, but this file is auto-generated by debhelper. The info file is created in the parent directory, debian/../. So I think this dir.gz shouldn't be generated automatically in such situations. I hope it helps. Regards, -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debhelper depends on: ii binutils 2.21.52.20110707-1 The GNU assembler, linker and bina ii dpkg-dev 1.16.0.3 Debian package development tools ii file 5.04-5+b1 Determines file type using magic ii html2text 1.3.2a-15 advanced HTML to text converter ii man-db2.6.0.2-1 on-line manual pager ii perl 5.12.4-1 Larry Wall's Practical Extraction ii perl-base 5.12.4-1 minimal Perl system ii po-debconf1.0.16+nmu1tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 0.59 tool that converts source archives -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634741: debhelper: Undesirable dir.gz autogeneration
Joey Hess, le Tue 19 Jul 2011 16:47:05 -0400, a écrit : jp wrote: I'm preparing a package which contains one single binary and some texinfo documentation. But when I do dpkg-buildpackage, a debian/package/usr/share/info/dir.gz is automatically generated. lintian doesn't like at all. In other words, it complains with the presence of dir.gz, but this file is auto-generated by debhelper. The info file is created in the parent directory, debian/../. So I think this dir.gz shouldn't be generated automatically in such situations. Your package's build system is generating this file, not debhelper. Oops, jp misunderstand what I told him. Of course debhelper doesn't generate it, Makefile does. But the problem still holds: with a standard ./configure make make install upstream package with texinfo documentation, %: dh $@ produces a package with a /usr/share/info/dir.gz. Shouldn't debhelper be able to drop dir? For now, the solution we have found is to tell dh_auto_install to install in debian/tmp, and create a debian/install which contains all the desired directories, which is tedious. Or another solution would be to remove the file explicitly after dh_auto_install, but dh_auto_install could as well just do it itself, to avoid the same tedious thing for all simple packages which have a texinfo documentation. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634741: debhelper: Undesirable dir.gz autogeneration
Samuel Thibault wrote: produces a package with a /usr/share/info/dir.gz. Shouldn't debhelper be able to drop dir? For now, the solution we have found is to tell dh_auto_install to install in debian/tmp, and create a debian/install which contains all the desired directories, which is tedious. Or another solution would be to remove the file explicitly after dh_auto_install, but dh_auto_install could as well just do it itself, to avoid the same tedious thing for all simple packages which have a texinfo documentation. dh_auto_install is just a generic way to run make install, it's not appropriate for it to go in and try to override the installation sequence. dh_install -X could be used, or you could fix the Makefile to not install it (why should an arbitrary make install overwrite /usr/share/info/dir.gz?), or possibly fix texinfo to not create it when building documentation. -- see shy jo signature.asc Description: Digital signature
Bug#634741: debhelper: Undesirable dir.gz autogeneration
Joey Hess, le Tue 19 Jul 2011 17:54:06 -0400, a écrit : Samuel Thibault wrote: produces a package with a /usr/share/info/dir.gz. Shouldn't debhelper be able to drop dir? For now, the solution we have found is to tell dh_auto_install to install in debian/tmp, and create a debian/install which contains all the desired directories, which is tedious. Or another solution would be to remove the file explicitly after dh_auto_install, but dh_auto_install could as well just do it itself, to avoid the same tedious thing for all simple packages which have a texinfo documentation. dh_auto_install is just a generic way to run make install, it's not appropriate for it to go in and try to override the installation sequence. dh_install -X could be used, In the case at stake, no, because it's a single-binary package, so everything is already installed. One thus has to pass --destdir to dh_auto_install, and then use dh_install by hand, it's a bit tedious. or you could fix the Makefile to not install it It's an automake Makefile, I don't really want to patch that :) (why should an arbitrary make install overwrite /usr/share/info/dir.gz?), It doesn't overwrites it, it updates it. make install is originally intended to install in the real place ;) or possibly fix texinfo to not create it when building documentation. That could be an option. Cc-ing automake: in the case DESTDIR is not empty, automake should perhaps prevent the dir.gz update. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
