NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: toolchain/58960: Missing support for _NETBSD_REVISIONID on various ports



The following reply was made to PR toolchain/58960; it has been noted by GNATS.

From: Thomas Klausner <wiz%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/58960: Missing support for _NETBSD_REVISIONID on
 various ports
Date: Sun, 5 Jan 2025 23:25:13 +0100

 On Sun, Jan 05, 2025 at 06:30:03PM +0000, Robert Elz via gnats wrote:
 >  Both do that.   Seperate per source files more accurately, as it also
 >  handles the case where only part of the tree has been updated (whatever
 >  happens with version control systems, my /usr/src will never contain
 >  directly checked out copies from one of those (with CVS, no CVS dirs for
 >  example), that is all elsewhere, /usr/src contains the sources used to
 >  build what I have installed in /bin /usr/bin ... and tends to get updated,
 >  by copying files, piecemeal when there is something changed in the full
 >  sources that I want (and sometimes when I simply want changes which will n
 >  ever be committed).
 
 I think you leave the path of what can be supported here.  If you
 start copying in files, then they might not have any CVS or RCS or
 whatever identifiers, and you'll be on your own wrt to keeping track
 of what files in particular a binary is using.
 
 I don't think this is something that can be usefully supported in
 general, and is not in the current way either. Some ways you are using
 it might be working for you, but I don't see it working in general.
 
 >  And no-one yet seems to have explained how this central identifier, that
 >  build.sh apparently obtains from somewhere, is to work when building things
 >  without using build.sh -- none of my kernel builds use build.sh, but I still
 >  like to be able to find out what's in them (as one example) and I routinely
 >  simply "make" on an updated utility or library which has a fix I want more
 >  urgently than I want to update everything.   That all needs to keep working.
 
 I didn't see the question posed anywhere yet either, so it's not
 surprising to me it hasn't been answered.
 
 Since you keep stating fiat statements, I'll do that too: No, that
 doesn't need to "keep working".
 
 I think it's a good enough state that when you run 'build.sh' and end
 up with a distribution, that you can identify which source code to
 check out to get the sources that can be used to rebuild these files
 (using build.sh again).
  Thomas
 


Home | Main Index | Thread Index | Old Index