Subject: Re: OK to put `uname -r` in "Release:" field of "send-pr"?
To: Luke Mewburn <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 10/18/2001 21:48:01
On Fri, 19 Oct 2001, Luke Mewburn wrote:
> On Thu, Oct 18, 2001 at 12:28:31PM -0500, Frederick Bruckman wrote:
> > Would anyone object if I change the "send-pr" Makefile to put the (build
> > time) result of `uname -r` into the "send-pr" script itself?
> 1. With the current method, we get DEFAULT_RELEASE from
> gnu/usr.bin/send-pr/Makefile, which is "<NetBSD current source date>"
> for -current, and a more specific version for a release.
Evidently, that's difficult for releng to keep up with! 3 PR's have
been filed for the same thing (DEFAULT_RELEASE in send-pr 1.5.2 says
"NetBSD 1.5.1"), and I sent an email to releng -- no response. The fix
suggested in PR 14217 is a laudable effort to make this maintenance
free in the future.
> 2. With `uname -r` at run-time, we get the kernel version of the running
> kernel, which might be newer than userland.
> 3. With `uname -r` at build time, we get the kernel version from that
> time of build. At best this reflects the status of the send-pr
For the normal case, where you "cvs update" the sources, then upgrade
the kernel, then upgrade userland, it doesn't matter...
> Also suggesting `ident foo` output for a program (and possibly
> that of any referenced shared libraries - a tool which uses
> file(1), ldd(1), and ident(1) would be useful here) could be of
I thought of the former, but I couldn't think of a message that fits
the pattern (one-line and concise).
> Out of these, I'd argue for `2.' as the solution. (Running system
> `uname -r`, update the send-pr prompts to remind people about
> kernel<->userland version skew)
OK. I realize now, the bad thing about `3', is that it would do
entirely the wrong thing for cross-builds.
I also thought of getting __NetBSD_Version__ out of <sys/param.h> and
massaging it, but that's complicated, and it still fails if the kernel
and userland are out of sync.
> (As a medium term project, we should ensure that we provide full
> CVS version strings in kernel source files. I compile with full
> debugging symbols (both kernel and userland), and for my kernels
> I only get CVS ids for ipfilter, some wscons stuff, and one audio
> driver. Something's not right there (IMHO)...)
I guess that means adding
to lots and lots of files in syssrc?