On 2013-06-05 18:57, Eric Haszlakiewicz wrote:
On Wed, Jun 05, 2013 at 11:53:32AM +0200, Johnny Billquist wrote:On 2013-06-05 11:45, Martin Husemann wrote:On Wed, Jun 05, 2013 at 09:36:37AM +0000, Thomas Mueller wrote:I noticed later, when upgrading NetBSD 6.1 and HEAD from source, that etcupdate wants to disable ttyE1, ttyE2 and ttyE3 in /etc/ttys. I was watchful and deleted the requested update of that file.I consider this a bug in etcupdate.How can that be a bug in etcupdate? All etcupdate tries to do is match /etc to what an /etc would look like on a virgin system.I thought it actually used the RCSid tags to figure out whether a change needs to be applied. Unless the default /etc/ttys actually changed from one 6.1 to HEAD, then etcupdate should do nothing, right?
Well, etcupdate actually do a full diff. The RCDid tag might be one of the things differing, but it will catch all kind of files with any differences.
But yes, if you haven't changed /etc/ttys locally, and it has not changed between 6.1 and HEAD, and you update from 6.1 to current, then right etcupdate will not suggest to do anything to /etc/ttys.
On new installations, the defaults are machine dependend, but at least i386 enables four VTs by default via sysinst. I guess amd64 should copy that (it happens in md_cleanup_install()).I might agree. But that is not something to blame on etcupdate.Why is it machine dependent? Are there arch's that don't use wscons, so the tty's to use end up being different?
Why do you assume all consoles are wscons based?
Johnny