If I were you adam I'd stop trying to interpret things, you aren't very good at it, not in the
failed attempt to guess at the kfreebsd logic, and not in this case. Just provide the data that is
requested and leave it at that, saves us a lot of time. The debugging information you finally
provided me, which I shouldn't have had to ask for twice, shows me the source of the issue clearly.
Now, the problem here is, that, this had escaped my memory, that debian's default /etc/issue is in
fact far superior in general in terms of output than the /etc/debian_version file is, no matter what
your pedantic view of the question is, the fact is, the default values stored there are almost
always and in most cases better than the data stored in /etc/debian_version, which is why it's used
for debian.
So I was wrong, /etc/issue for debian and ubuntu is the preferred source, but I'll switch this based
on the reasoning below.
Since you are the first person ever to take issue with this, so to speak, I'm not super sure I
should do anything about this, because MOST users will get better data and results from that source
than from /etc/debian_version.
I can't guess what you stuck in your /etc/issue, but there can be an argument made to extend the
checks of /etc/issue slightly in this case, though it's hard to make this type of change, I'm
certainly not going to make it worse for most people just to make one single issue reporter happy.
So it's the old thing, the good of the many outweighs the good of the one, in
this case.
But there is another way I can see, because basically now the os-release stores the default
/etc/issue value in PRETTY_NAME, and now that os-release is more common (this logic was written LONG
before os-release came into being), I think the solution is to just switch to using the pretty name
value of os-release in debian/duvian/ubuntu's cases if my data shows that's consistently good.
Now, of course, this will immediately trigger a cascade of errors where people expected to see x and
suddenly see y, totally unpredictable, which is what happens when you change core things,
particularly only for a single person, a risky proposition, though I can check some of my os-release
data from user datasets I've gathered over the past 4 years or so, that should be enough.
This option didn't exist before because it took a long time for os-release to filter down and become
standard in almost all extent debian/ubuntu versions.
So that seems like a good fix, but that's if any only if os-release is basically consistent and
usable, ie, it always contains the same data for almost all users as /etc/issue did. If it doesn't
in some cases, then I'd have to make the changes more granular. If I find enough cases where
os-release values are not good, then I'll have to probably just ignore this issue and leave it as it
is, because I'm not going to mess things up for more than 1 person just to make 1 person happy.
So we'll see how this goes.
