On Feb 15, 2013, at 3:14 PM, Regid Ichira wrote: > --- On Tue, 2/12/13, Charles Lepple <[email protected]> wrote: > >> Regid, >> >> You suggested we remove nut_version.h from the .orig.tar.gz >> for NUT: >> >> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613643> >> >> >> The original intent was that nut_version.h would be >> generated from "make dist" (or "make distcheck*") when the >> official nut-X.Y.Z.tar.gz tarball is created. At that point, >> it is safe to assume that there is no longer any local >> version control information (originally SVN, now Git) to >> determine what to put in nut_version.h. >> >> How would you recommend that we handle keeping this file >> such that we do not trigger a warning in dpkg-source? > > > I can't tell. I am not familiar with the user interface, nor > with the internals, of Debian packaging to say how to do that, or > even if it is doable. I tried to read the manual page of > dpkg-source. It does seem to have tools to handle this case. > But, as I wrote, someone more knowledgeable might be able to > interpret it much better.
Let's step back a bit. Is the warning a big deal for a Debian package, or can we just add one of those lintian overrides for it? > >> >> We could patch around this (currently, NUT build from a >> tarball with Git installed yields a version like >> "2.6.5-Unversioned directory"), but I think the easiest way >> is to just leave nut_version.h in the tarball. >> > > > Pergaps you should patch it in this way, or use more then one > file, or something similar? I do get the impression that > currently, the version file is meant for a developer and for the > distributer. While you also require the user, the one that just > build the package from source, mess with it. Perhaps there should > be upsnetworktools.org_ver, distributer_ver, developer_ver, Where > the developer_ver, if set, overrides the distributer_ver, which, > if set, overrides the upsnetworktools.org_ver? Honestly, I was trying to do something simple, such that someone building from a tarball doesn't need to mess with anything (since nut_version.h would be created during "make dist"). The idea for a developer is that nut_version.h would automatically capture the current commit state without them needing to edit anything, either. A distributor could easily edit the version in configure.in, and it would be somewhat orthogonal to the commit-based version information (although concatenated together). -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
