Re: Debian testing - release number

2018-07-13 Thread David Wright
On Wed 11 Jul 2018 at 11:53:29 (+), Curt wrote:
> On 2018-07-10, David Wright  wrote:

Yes, I wrote a post on 2018-07-10 but you haven't quoted any of it here.

> You following up to Woole[d]ge:
> 
>  Hmm, I struggle to see the connection between what I asked for and
>  what you wrote. From your later post, I guess the answer is that
>  editing /etc/debian_version risks provoking expletives from other
>  users of the system.
> 
>  That said, I do agree with what you wrote.
> 
> So there was an equivocal quality there, Dav[id], as to which of Woole[d]ge's
> articles "what you wrote" was referring (the one you were following up
> to above, or the "fucking" one below to which you alluded--so I *asked*,
> indicated by my question mark, which my tone may have rendered somehow
> accusatory).

Your tone, and your language, indicated that the question was rhetorical.
But you are now peddling "an equivocal quality" argument by stripping
the quotation above away from the post it belonged to:

 https://lists.debian.org/debian-user/2018/07/msg00185.html
'Your hypothetical case describes a shell script that is supposed to
 detect what version of Debian it's running on, for whatever reason.
 If this script doesn't know how to handle the string "testing/unstable"
 then it's doing a really crappy job of "supporting" Debian systems.'

and unilaterally deciding that it's the response to a post that (a)
I disagree with and (b) that's actually in a different subthread, the
Nicholas Geovanis one:

 167  sL 180704  Richard Hector   (4.2K)  └─>
 168   L 180704   John Crawley(2.7K)├─>
 169   L 180705   Curt(1.0K)├─>
 170   L 180705Joe(0.8K)│ └─>
 171   L 180705   Curt(1.0K)│   ├─>
 172   F 180705  To Debian-User   (2.1K)│   └─>
 173   L 180705   Greg Wooledge   (0.6K)│ └─>
 174   F 180705  To Debian-User   (1.5K)│   └─>
 175   L 180705   Greg Wooledge   (0.9K)│ └─> ← I commented on this 
(msg00185.html)
 176   L 180705 Nicholas Geovanis (1.4K)│   ├─>
 177   L 180705Joe(1.1K)│   │ ├─>
 178   L 180705   Greg Wooledge   (1.0K)│   │ └─>
 179   L 180705 Nicholas Geovanis (0.9K)│   │   └─>
 180   L 180705   Greg Wooledge   (0.4K)│   │ └─> ← contains 
the f-word (msg00191.html)
 181   L 180705 Nicholas Geovanis (1.5K)│   │   └─>
 182   F 180705  To Debian-User   (1.8K)│   │ ├─>
 183  sL 180706   The Wanderer(2.5K)│   │ └─>
 184   L 180706   Curt(1.5K)│   │   └─>
 185   F 180705  To Debian-User   (1.2K)│   └─> ← my comment under 
discussion (msg00199.html)
 186   L 180706   Curt(1.5K)│ └─>
 187   L 180706   Greg Wooledge   (0.7K)│   ├─>
 188   L 180706   Curt(0.1K)│   │ └─>
 189   L 180706 davidson  (1.5K)│   │   └─>
 190   L 180707   Curt(1.9K)│   │ └─>
 191   L 180709   Greg Wooledge   (1.2K)│   │   └─>
 192   L 180709   Curt(0.5K)│   │ └─>

There's no reference to Message-id: 0180705204615.xlgol2g2kuace...@eeg.ccf.org
(that's msg00191.html) in my msg00199.html. Check it for yourself.
Perhaps it's threading as well as quoting that's causing you difficulty.

> I do admit that I believed the latter interpretation
> without even considering the real possibility that it was indeed the
> former, probably because of a minor incident in the Latex/PDF thread we were
> both involved in a few moons ago, a can of beans not worth opening.  

Without any reference, it's difficult to know what you're talking about.
But I'm sorry that it's obviously bugging you.

Here's the contents of the post that you keep wanting to attach
my comment to. If it helps, I'll annotate it here.

> The Woole[d]ge post:
> 
>  It is not a fucking configuration file that you edit.

https://lists.debian.org/debian-devel/2001/01/msg00502.html

>  It is supposed to be read only.
> 
>  Only a crazy idiot would manually edit the file that tells you what
>  version of the OS you're running.

https://lists.debian.org/debian-devel/2001/01/msg00550.html
https://lists.debian.org/debian-devel/2001/01/msg00558.html

>  It would be like editing registry entries in Microsoft Windows to make
>  it look like you're running a different version of Windows.

I lost track of windows versions around 1996 and never got beyond
DOS 6.22 for serious work. Apart from knowing that there are versions
7 (good?), 8 (bad?) and 10 (current) still around, I don't know any
more than that, so the metaphor is lost on me.

Cheers,
David.



Re: Debian testing - release number

2018-07-11 Thread Curt
On 2018-07-10, David Wright  wrote:
 
You following up to Woolege:

 Hmm, I struggle to see the connection between what I asked for and
 what you wrote. From your later post, I guess the answer is that
 editing /etc/debian_version risks provoking expletives from other
 users of the system.

 That said, I do agree with what you wrote.

So there was an equivocal quality there, Dave, as to which of Woolege's
articles "what you wrote" was referring (the one you were following up
to above, or the "fucking" one below to which you alluded--so I *asked*,
indicated by my question mark, which my tone may have rendered somehow
accusatory). I do admit that I believed the latter interpretation
without even considering the real possibility that it was indeed the
former, probably because of a minor incident in the Latex/PDF thread we were
both involved in a few moons ago, a can of beans not worth opening.  

The Woolege post:

 It is not a fucking configuration file that you edit.

 It is supposed to be read only.

 Only a crazy idiot would manually edit the file that tells you what
 version of the OS you're running.

 It would be like editing registry entries in Microsoft Windows to make
 it look like you're running a different version of Windows.

Anyway, have a nice day.



Re: Debian testing - release number

2018-07-10 Thread David Wright
On Fri 06 Jul 2018 at 08:41:58 (+), Curt wrote:
> On 2018-07-06, David Wright  wrote:
> 
> > Hmm, I struggle to see the connection between what I asked for and
> > what you wrote. From your later post, I guess the answer is that
> > editing /etc/debian_version risks provoking expletives from other
> > users of the system.
> >
> > That said, I do agree with what you wrote.
> 
> So wait, now, after saying this
> 
>  What seems to be lost on people who feel a pressing need for
>  /etc/debian_version to contain a number to satisfy some script that
>  they have written (which seems to be the usual reason) is that
>  /etc/debian_version is a configuration file. Look in the
>  .deb file and there it is, along with /etc/issue{,.net} which
>  determine how you are greeted {locally,remotely}. So admins are
>  free to set them all how they like.

That paragraph is a correct quotation of what I wrote.

> we discover that what you actually believe is, although admins are free to do
> so (like you're free to blindfold yourself and jog in the middle of the 
> freeway
> at rush hour in L.A with a broom sticking out of your wazoo), you'd have to be
> insane to actually edit /etc/debian_version, which is *not*, in fact, a
> configuration file

This is something you just made up and is unrelated to what I have written.

> (because that's what Wooledge said that you're agreeing
> with here)?

[I think you mean "because that's what Wooledge said, which you're agreeing
with here".]

Perhaps you have temporarily forgotten how quoting should work on a
mailing list, and therefore your interpretation of
https://lists.debian.org/debian-user/2018/07/msg00199.html
is completed erroneous. Read what I posted:

1)

"[DW] Hmm, I struggle to see the connection between what I asked for
 and what you wrote."

In other words, this reply:

'[GW] Your hypothetical case describes a shell script that is
 supposed to detect what version of Debian it's running on,
 for whatever reason.
 If this script doesn't know how to handle the string
 "testing/unstable" then it's doing a really crappy job of
 "supporting" Debian systems.'

does not answer:

"[DW] Would you explain what is unsafe about it and why
 /etc/debian_version is a configuration file, or offer
 a sensible alternative."

2)

"[DW] That said, I do agree with what you wrote."

In other words, I agree with the statement I quoted there:

'[GW] Your hypothetical case describes a shell script that is
 supposed to detect what version of Debian it's running on,
 for whatever reason.
 If this script doesn't know how to handle the string
 "testing/unstable" then it's doing a really crappy job of
 "supporting" Debian systems.'

It doesn't mean I agree with everything they ever wrote in the thread
on the matter, just what I quoted, which is why I quoted it.

> So, Joey Hess is a crazy idiot, for instance?

Why would you think of calling Joey a "crazy idiot"?

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81249
> 
>  Local changes made to /etc/debian_version (in this case changing it from
>  "testing/unstable" to "unstable" since that is what this system is really
>  using) are wiped out when the package is upgraded or reinstalled:

The evidence presented in the bug report clearly shows that
/etc/debian_version gets overwritten, so one has to assume that,
at the time, it wasn't flagged as a conffile. That's supported
by typing:

$ zgrep -A7 '(2.2.8)' /usr/share/doc/base-files/changelog.gz

There was some debate around this time about what /etc/debian_version
should contain during development, as you can see with:

$ zgrep -A16 '(2.2.6)' /usr/share/doc/base-files/changelog.gz

The fact that /etc/debian_version *is* a *configuration* file
was clearly promulgated in:

https://lists.debian.org/debian-devel/2001/01/msg00502.html

Cheers,
David.



Re: Debian testing - release number

2018-07-09 Thread Curt
On 2018-07-09, Greg Wooledge  wrote:
> On Sat, Jul 07, 2018 at 07:55:26AM +, Curt wrote:
>> On 2018-07-07, davidson  wrote:
>> > Speculation: I suspect that the listserv software escapes "From" after
>> > a newline, and that its chosen escape is synonymous with the embedded
>> > quote character.[1]
>
>> The culprit is therefore Wooledge himself.
>
> The culprit is "mbox". 
>

I meant only that you were the author of the malicious comment.



Re: Debian testing - release number

2018-07-09 Thread Greg Wooledge
On Sat, Jul 07, 2018 at 07:55:26AM +, Curt wrote:
> On 2018-07-07, davidson  wrote:
> > Speculation: I suspect that the listserv software escapes "From" after
> > a newline, and that its chosen escape is synonymous with the embedded
> > quote character.[1]

> The culprit is therefore Wooledge himself.

The culprit is "mbox". 

Because the 5-byte string "From " at the start of a line delimits new
messages in "mbox" formats, many mail systems will alter the body of a
message, placing ">" in front of leading "From " strings.  This happens
quite frequently.

As JDEBP writes on the web page cited above:

  The "mboxo" mailbox format uses irreversible "From quoting" that
  corrupts messages. Before a message is appended to a "mboxo" mailbox
  file, it is transformed. Any line of the message, in either the
  header or the body, that begins with the five characters 'F', 'r',
  'o', 'm', and ' ' has a single '>' character prepended to it. This
  transformation is irreversible because it is impossible to distinguish,
  when reading a message, a line that began '>From ' in the original
  message from a line that began 'From ' in the original message and
  that was subsequently transformed.



Re: Debian testing - release number

2018-07-07 Thread Curt
On 2018-07-07, davidson  wrote:
> On Fri, 6 Jul 2018, Curt wrote:
>
>> On 2018-07-06, Greg Wooledge  wrote:
>>>
 From this, I conclude that Joey Hess is a skilled manipulator.
>>>
>>
>> (I didn't say this.)
>
> Observation: That line begins with "From".
>
> Speculation: I suspect that the listserv software escapes "From" after
> a newline, and that its chosen escape is synonymous with the embedded
> quote character.[1]
>
> I'm pretty sure it did this when passing on a message of my own, here:
>
>
> https://lists.debian.org/msgid-search/alpine.deb.2.10.1807011736220.15...@freevolt.org
>
> In that message, the line-initial phrase "From the horse's mouth:" was
> my own. I'm certain I didn't attribute it to anyone else, in the
> message I sent to the list. But in the copy I received from the list,
> and in the archives, it looks like I did.
>
> Conclusion: If you're going to say anything really heinous on this
> list, make sure to put it in a line that begins with the word "From".

The culprit is therefore Wooledge himself.

> And, whatever the facts, it was nice of Curt to co-author this verse
> with Mr Guthrie:
>
> This land is your land This land is my land
>>From California to the New York island;
>>From the red wood forest to the Gulf Stream waters
> This land was made for you and Me.

Looks like a convincing demonstration. Except in this case
I won't disclaim authorship.

> NOTES
>
> 1. More discussion here, at the end of the second paragraph:
>
>   The Jargon File Part I. Introduction
>   Chapter 6. Email Quotes and Inclusion Conventions
>   http://www.catb.org/jargon/html/email-style.html
>

>From this moment on,
You for me dear,
Only two for tea dear,
>From this moment on,

>From this happy day,
No more blue songs,
Only hoop-de-doo songs,
>From this moment on

Give my regards to Cole P. (though he's passed now these many years).



Re: Debian testing - release number

2018-07-06 Thread davidson

On Fri, 6 Jul 2018, Curt wrote:


On 2018-07-06, Greg Wooledge  wrote:



From this, I conclude that Joey Hess is a skilled manipulator.




(I didn't say this.)


Observation: That line begins with "From".

Speculation: I suspect that the listserv software escapes "From" after
a newline, and that its chosen escape is synonymous with the embedded
quote character.[1]

I'm pretty sure it did this when passing on a message of my own, here:

  
https://lists.debian.org/msgid-search/alpine.deb.2.10.1807011736220.15...@freevolt.org

In that message, the line-initial phrase "From the horse's mouth:" was
my own. I'm certain I didn't attribute it to anyone else, in the
message I sent to the list. But in the copy I received from the list,
and in the archives, it looks like I did.

Conclusion: If you're going to say anything really heinous on this
list, make sure to put it in a line that begins with the word "From".

And, whatever the facts, it was nice of Curt to co-author this verse
with Mr Guthrie:

This land is your land This land is my land

From California to the New York island;
From the red wood forest to the Gulf Stream waters

This land was made for you and Me.

NOTES

1. More discussion here, at the end of the second paragraph:

 The Jargon File Part I. Introduction
 Chapter 6. Email Quotes and Inclusion Conventions
 http://www.catb.org/jargon/html/email-style.html

--


From my branded electronic device, this was sent.

  -- Yoda



Re: Debian testing - release number

2018-07-06 Thread Curt
On 2018-07-06, The Wanderer  wrote:
>
> On 2018-07-05 at 17:29, Nicholas Geovanis wrote:
>
>> But what I'm trying to point out here is that there seems to be no
>> such canonical (sic) Debian tool which CAN tell me what release and
>> version I'm running.
>
> That's not true. /etc/debian_version, if not modified by the sysadmin,
> should always tell you this.
>

/usr/share/doc/base-files/FAQ

Q. I upgraded my system to the testing distribution and now my
/etc/issue says "buster/sid". Should it not read "buster" or "testing"?

Q. I upgraded my system to the unstable distribution and now my
/etc/issue says "buster/sid". Should it not read "sid" or "unstable"?

A. That would be nice, but it is not possible because of the way the
testing distribution works. Packages uploaded for unstable reach
testing after ten days, provided they are built for every released
architecture, have no RC-bugs and their dependencies may be met in
testing. You should consider the testing and unstable distributions as
two sides of the same coin. Since the base-files package in testing
was initially uploaded for unstable, the only sensible /etc/issue to
have is one that is both valid for testing and unstable, hence
"buster/sid" (or whatever is appropriate).

Q. Ok, but how do I know which distribution I'm running?

A. If you are running testing or unstable, then /etc/debian_version is
not a reliable way to know that anymore. Looking at the contents of
your /etc/apt/sources.list file is probably a much better way.





Re: Debian testing - release number

2018-07-06 Thread The Wanderer
On 2018-07-05 at 17:29, Nicholas Geovanis wrote:

> But what I'm trying to point out here is that there seems to be no 
> such canonical (sic) Debian tool which CAN tell me what release and 
> version I'm running.

That's not true. /etc/debian_version, if not modified by the sysadmin,
should always tell you this.

However, it will not always tell you a number - because not every Debian
which you might be running *has* a version number.


According to (my understanding of what's been stated in) this thread,
testing has not been assigned a version number yet; by the time it gets
one, it is not testing anymore, it is stable.

Also, sid will - almost by definition - never have a version number.

What would the tool you're asking for provide in such cases, and where
is it supposed to get that information?

The answers which Debian appears to have arrived at are "the codename"
and "/etc/debian_version".

That means that, in such cases, the tool will not provide a number.

If you aren't willing to accept that result, you'll have to come up with
your own answer to those two questions.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Debian testing - release number

2018-07-06 Thread Curt
On 2018-07-06, Greg Wooledge  wrote:
>
>>From this, I conclude that Joey Hess is a skilled manipulator.
>

(I didn't say this.)



Re: Debian testing - release number

2018-07-06 Thread Greg Wooledge
On Fri, Jul 06, 2018 at 08:41:58AM +, Curt wrote:
> So, Joey Hess is a crazy idiot, for instance?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81249

That was written in 2001.  One hopes that he has learned something in
the 17 years since then.  I certainly have.

Reading along to the end of that bug report, it appears that Joey
Hess managed to convince the maintainers of base-files to mark
/etc/debian_version as a conffile.  This is still its state today --
I just checked it in base-files_9.9+deb9u4_amd64.deb.

>From this, I conclude that Joey Hess is a skilled manipulator.

That doesn't stop him from also being a crazy idiot, at least on this
particular issue.



Re: Debian testing - release number

2018-07-06 Thread Curt
On 2018-07-06, David Wright  wrote:

> Hmm, I struggle to see the connection between what I asked for and
> what you wrote. From your later post, I guess the answer is that
> editing /etc/debian_version risks provoking expletives from other
> users of the system.
>
> That said, I do agree with what you wrote.

So wait, now, after saying this

 What seems to be lost on people who feel a pressing need for
 /etc/debian_version to contain a number to satisfy some script that
 they have written (which seems to be the usual reason) is that
 /etc/debian_version is a configuration file. Look in the
 .deb file and there it is, along with /etc/issue{,.net} which
 determine how you are greeted {locally,remotely}. So admins are
 free to set them all how they like.

we discover that what you actually believe is, although admins are free to do
so (like you're free to blindfold yourself and jog in the middle of the freeway
at rush hour in L.A with a broom sticking out of your wazoo), you'd have to be
insane to actually edit /etc/debian_version, which is *not*, in fact, a
configuration file (because that's what Wooledge said that you're agreeing
with here)?

So, Joey Hess is a crazy idiot, for instance?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81249

 Local changes made to /etc/debian_version (in this case changing it from
 "testing/unstable" to "unstable" since that is what this system is really
 using) are wiped out when the package is upgraded or reinstalled:

> Cheers,
> David.
>
>




Re: Debian testing - release number

2018-07-05 Thread David Wright
On Thu 05 Jul 2018 at 14:08:21 (-0400), Greg Wooledge wrote:
> On Thu, Jul 05, 2018 at 12:57:34PM -0500, David Wright wrote:
> > On Thu 05 Jul 2018 at 12:42:36 (-0400), Greg Wooledge wrote:
> > > On Thu, Jul 05, 2018 at 11:06:22AM -0500, David Wright wrote:
> > > > But if you're a sysadmin who has a script that wants/needs a version
> > > > *number* for any reason, then /etc/debian_version is the safest file
> > > > to modify.
> > > 
> > > I strongly disagree.  The safest file to modify would be the broken
> > > shell script that needs a "release number".
> > 
> > Would you explain what is unsafe about it and why /etc/debian_version
> > is a configuration file, or offer a sensible alternative.
> 
> Your hypothetical case describes a shell script that is supposed to
> detect what version of Debian it's running on, for whatever reason.
> 
> If this script doesn't know how to handle the string "testing/unstable"
> then it's doing a really crappy job of "supporting" Debian systems.

Hmm, I struggle to see the connection between what I asked for and
what you wrote. From your later post, I guess the answer is that
editing /etc/debian_version risks provoking expletives from other
users of the system.

That said, I do agree with what you wrote.

Cheers,
David.



Re: Debian testing - release number

2018-07-05 Thread David Wright
On Thu 05 Jul 2018 at 16:29:30 (-0500), Nicholas Geovanis wrote:
> On Thu, Jul 5, 2018 at 3:46 PM Greg Wooledge  wrote:
> >
> > On Thu, Jul 05, 2018 at 03:27:44PM -0500, Nicholas Geovanis wrote:
> > > (1) You foolishly relied on the value in /etc/debian_version when
> >
> > It is not a fucking configuration file that you edit.
> > It is supposed to be read only.
> > Only a crazy idiot would manually edit the file that tells you what
> > version of the OS you're running.
> > It would be like editing registry entries in Microsoft Windows to make
> > it look like you're running a different version of Windows.
> 
> All perfectly correct, valid statements in my view Greg.
> But that wasn't my question.
> Question: What is the correct tool to TELL you what Debian version you
> are running?
> Mr. Armstrong suggests that dpkg is a better choice and that sounds better 
> than
> the apt-related commands. But Joe A followed up with:
> "But it's odd that you're the first to point out (indirectly) that
> knowing the version of Debian isn't that useful."
> I did no such thing. I think it's very useful. But what I'm trying to
> point out here
> is that there seems to be no such canonical (sic) Debian tool which CAN tell 
> me
> what release and version I'm running. Otherwise the answer from Joe Armstrong
> would have been more like "run command XYZ which tells you version=3.4.5".
> So there doesn't seem to be such a tool. That was my point.
> Now we know that the answer "look at /etc/debian_version" is the wrong answer.
> So again: What is the correct, intended, standard Debian tool which tells me
> the installed, running Debian release and version number?

Oh, that's easy. The intended one is /etc/os-release ± lsb_release
(command) if it's installed. Though a closer approach might be
/etc/apt/sources.list.

Cheers,
David.



Re: Debian testing - release number

2018-07-05 Thread Nicholas Geovanis
On Thu, Jul 5, 2018 at 3:46 PM Greg Wooledge  wrote:
>
> On Thu, Jul 05, 2018 at 03:27:44PM -0500, Nicholas Geovanis wrote:
> > (1) You foolishly relied on the value in /etc/debian_version when
>
> It is not a fucking configuration file that you edit.
> It is supposed to be read only.
> Only a crazy idiot would manually edit the file that tells you what
> version of the OS you're running.
> It would be like editing registry entries in Microsoft Windows to make
> it look like you're running a different version of Windows.

All perfectly correct, valid statements in my view Greg.
But that wasn't my question.
Question: What is the correct tool to TELL you what Debian version you
are running?
Mr. Armstrong suggests that dpkg is a better choice and that sounds better than
the apt-related commands. But Joe A followed up with:
"But it's odd that you're the first to point out (indirectly) that
knowing the version of Debian isn't that useful."
I did no such thing. I think it's very useful. But what I'm trying to
point out here
is that there seems to be no such canonical (sic) Debian tool which CAN tell me
what release and version I'm running. Otherwise the answer from Joe Armstrong
would have been more like "run command XYZ which tells you version=3.4.5".
So there doesn't seem to be such a tool. That was my point.
Now we know that the answer "look at /etc/debian_version" is the wrong answer.
So again: What is the correct, intended, standard Debian tool which tells me
the installed, running Debian release and version number?



Re: Debian testing - release number

2018-07-05 Thread Greg Wooledge
On Thu, Jul 05, 2018 at 03:27:44PM -0500, Nicholas Geovanis wrote:
> (1) You foolishly relied on the value in /etc/debian_version when

It is not a fucking configuration file that you edit.

It is supposed to be read only.

Only a crazy idiot would manually edit the file that tells you what
version of the OS you're running.

It would be like editing registry entries in Microsoft Windows to make
it look like you're running a different version of Windows.



Re: Debian testing - release number

2018-07-05 Thread Joe
On Thu, 5 Jul 2018 14:57:03 -0500
Nicholas Geovanis  wrote:

> I am rightly accused of relying too heavily on /etc/debian_version to
> detect my running release. But it seems clear
> to me that the "right", canonical way to detect this is to query the
> installed package base to extract a version/release
> number from a package name and/or version. So surely there is an
> "approved" tool for doing that. Hopefully OTHER THAN
> apt, aptitude, synaptic or apt-get; ideally simpler and easier to
> script than that.

I would expect dpkg to be a better bet than apt, as it's more primitive.
Manually, I use dpkg -l with a grep to find version numbers.

But it's odd that you're the first to point out (indirectly) that
knowing the version of Debian isn't that useful. This is *Debian*.
Quite a few users will have at least one backport or locally-compiled
package, and there will be a few people who have almost tamed a
frankendebian.

If your application depends on a particular version of a *package*,
then it makes sense to enquire which version of that package is
installed, not which version of Debian is running.

-- 
Joe



Re: Debian testing - release number

2018-07-05 Thread Nicholas Geovanis
On Thu, Jul 5, 2018 at 3:16 PM Greg Wooledge  wrote:
>
> On Thu, Jul 05, 2018 at 02:57:03PM -0500, Nicholas Geovanis wrote:
> > So surely there is an
> > "approved" tool for doing that. Hopefully OTHER THAN
> > apt, aptitude, synaptic or apt-get; ideally simpler and easier to
> > script than that.
> > So what is that tool?
>
> #!/bin/bash
> if [[ ! -r /etc/debian_version ]]; then
.
> esac

Which illustrates the exact problem in this situation: There is no such tool.
See what you did?
(1) You foolishly relied on the value in /etc/debian_version when
you already know that it isn't the right, canonical value. Because it won't work
on certain debian releases.
(2) I didn't ask for a script, I asked for a pre-existing tool. You demonstrated
that there is no such tool other than /etc/debian_version.

So ;-) Once again, what is the one single, concise tool that tells me which
debian version I'm running.. :-)



Re: Debian testing - release number

2018-07-05 Thread Greg Wooledge
On Thu, Jul 05, 2018 at 02:57:03PM -0500, Nicholas Geovanis wrote:
> I am rightly accused of relying too heavily on /etc/debian_version to
> detect my running release. But it seems clear
> to me that the "right", canonical way to detect this is to query the
> installed package base to extract a version/release
> number from a package name and/or version. So surely there is an
> "approved" tool for doing that. Hopefully OTHER THAN
> apt, aptitude, synaptic or apt-get; ideally simpler and easier to
> script than that.
> So what is that tool?

#!/bin/bash
if [[ ! -r /etc/debian_version ]]; then
  echo "This script only supports Debian systems." >&2
  exit 1
fi

read -r debver < /etc/debian_version
case $debver in
  *unstable*) : code to handle testing/unstable ;;
  1[0-9].*)   : code to handle the fture {probably just abort} ;;
  9.*): code to handle stretch ;;
  8.*): code to handle jessie ;;
  *)  : code to handle "too old" or "unknown" {probably just abort} ;;
esac



Re: Debian testing - release number

2018-07-05 Thread Nicholas Geovanis
I am rightly accused of relying too heavily on /etc/debian_version to
detect my running release. But it seems clear
to me that the "right", canonical way to detect this is to query the
installed package base to extract a version/release
number from a package name and/or version. So surely there is an
"approved" tool for doing that. Hopefully OTHER THAN
apt, aptitude, synaptic or apt-get; ideally simpler and easier to
script than that.
So what is that tool?
On Thu, Jul 5, 2018 at 1:08 PM Greg Wooledge  wrote:
>
> On Thu, Jul 05, 2018 at 12:57:34PM -0500, David Wright wrote:
> > On Thu 05 Jul 2018 at 12:42:36 (-0400), Greg Wooledge wrote:
> > > On Thu, Jul 05, 2018 at 11:06:22AM -0500, David Wright wrote:
> > > > But if you're a sysadmin who has a script that wants/needs a version
> > > > *number* for any reason, then /etc/debian_version is the safest file
> > > > to modify.
> > >
> > > I strongly disagree.  The safest file to modify would be the broken
> > > shell script that needs a "release number".
> >
> > Would you explain what is unsafe about it and why /etc/debian_version
> > is a configuration file, or offer a sensible alternative.
>
> Your hypothetical case describes a shell script that is supposed to
> detect what version of Debian it's running on, for whatever reason.
>
> If this script doesn't know how to handle the string "testing/unstable"
> then it's doing a really crappy job of "supporting" Debian systems.
>



Re: Debian testing - release number

2018-07-05 Thread Greg Wooledge
On Thu, Jul 05, 2018 at 12:57:34PM -0500, David Wright wrote:
> On Thu 05 Jul 2018 at 12:42:36 (-0400), Greg Wooledge wrote:
> > On Thu, Jul 05, 2018 at 11:06:22AM -0500, David Wright wrote:
> > > But if you're a sysadmin who has a script that wants/needs a version
> > > *number* for any reason, then /etc/debian_version is the safest file
> > > to modify.
> > 
> > I strongly disagree.  The safest file to modify would be the broken
> > shell script that needs a "release number".
> 
> Would you explain what is unsafe about it and why /etc/debian_version
> is a configuration file, or offer a sensible alternative.

Your hypothetical case describes a shell script that is supposed to
detect what version of Debian it's running on, for whatever reason.

If this script doesn't know how to handle the string "testing/unstable"
then it's doing a really crappy job of "supporting" Debian systems.



Re: Debian testing - release number

2018-07-05 Thread David Wright
On Thu 05 Jul 2018 at 12:42:36 (-0400), Greg Wooledge wrote:
> On Thu, Jul 05, 2018 at 11:06:22AM -0500, David Wright wrote:
> > But if you're a sysadmin who has a script that wants/needs a version
> > *number* for any reason, then /etc/debian_version is the safest file
> > to modify.
> 
> I strongly disagree.  The safest file to modify would be the broken
> shell script that needs a "release number".

Would you explain what is unsafe about it and why /etc/debian_version
is a configuration file, or offer a sensible alternative.

> Either that, or the brain of the system administrator who installed
> testing or unstable on this production system (because what other kind
> of system would be running a broken shell script to detect a release
> number that doesn't necessarily exist).

You've lost me. My assumption would be that the misguided script
writer wrote the script(s) on a stable (or older) system without
realising that unreleased systems don't have a numeric debian_version.

They might only realise their mistake when they needed to install/
upgrade to testing for some unrelated reason and some of their
scripts (or even programs) started throwing errors.

If they were trying to meet pressing deadlines, I would not deny them
the sticking plaster approach in favour of brain surgery or
potentially long debugging sessions. "Stupid" or not, they deserve
help, commonly known as a workaround or hack.

There's plenty of evidence that some people here employ far worse
hacks upon workarounds upon hacks than this one. It's human nature.

Cheers,
David.



Re: Debian testing - release number

2018-07-05 Thread Greg Wooledge
On Thu, Jul 05, 2018 at 11:06:22AM -0500, David Wright wrote:
> But if you're a sysadmin who has a script that wants/needs a version
> *number* for any reason, then /etc/debian_version is the safest file
> to modify.

I strongly disagree.  The safest file to modify would be the broken
shell script that needs a "release number".

Either that, or the brain of the system administrator who installed
testing or unstable on this production system (because what other kind
of system would be running a broken shell script to detect a release
number that doesn't necessarily exist).



Re: Debian testing - release number

2018-07-05 Thread David Wright
On Thu 05 Jul 2018 at 11:53:45 (+0100), Joe wrote:
> On Thu, 5 Jul 2018 10:09:36 + (UTC)
> Curt  wrote:
> 
> 
> > 
> > The problem I'm looking at is that the Debian testing/unstable
> > releases do not have a version number and are not going to be
> > receiving one any time soon (the tradition of not according a number
> > to these two releases being of the utmost venerability). 
> 
> How can they? They are never released, and unstable receives new
> software, sometimes new software *versions*, minute by minute. I don't
> know how much new code unstable gets per day, but my workstation
> installation typically downloads something of the order of 50MB,
> usually dozens of packages. Testing is a bit more stable, but
> outside the freeze, basically follows unstable with about ten days'
> delay for a given package. In that context, what can 'release number'
> mean? It can only make sense for stable.

Of course; that's the argument made by the release managers, and it's
the rule that was broken when "1.0" was released in error, which is
why it was skipped, buzz becoming 1.1. What the release managers
rightly resist is wishlist reports for changing the released values
given by debian_version and its relatives like os-release and
lsb_release. I expect distributors follow this policy.

But if you're a sysadmin who has a script that wants/needs a version
*number* for any reason, then /etc/debian_version is the safest file
to modify. It guarantees that released Debian software won't change
its behaviour (doing so would be a bug), but unreleased and
third-party software would behave as the sysadmin desires.

But playing devil's advocate, there's no reason why Debian couldn't
have made a different choice. The obvious one, which I've seen
elsewhere, is to reserve the value N.0 for testing (10.0 in the
case of buster). The new release would be N.1 with point releases
as before.

Myself, I prefer dealing with codenames anyway, so I have no axe
to grind. I don't modify debian_version, but use the first line
of sources.list for my own purposes, mainly the selection of
configuration files by symlinks.

Cheers,
David.



Re: Debian testing - release number

2018-07-05 Thread David Wright
On Thu 05 Jul 2018 at 12:58:21 (+1200), Richard Hector wrote:
> On 05/07/18 03:53, David Wright wrote:
> > On Wed 04 Jul 2018 at 13:18:14 (+1200), Richard Hector wrote:
> >> On 02/07/18 05:31, David Wright wrote:
> >>> On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:
>  On 28/06/18 16:40, David Wright wrote:
> > On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
> >> I am wondering if it is possible to get the debian release number
> >> for debian testing (and maybe sid) from command line?
> >
> > Yes.
> >
> > # cat > /etc/debian_version
> > Write whatever you want here
> > ^D
> >
> > Job done. (That's a control-D.)
> >
> > Whether it's advisable to depend on its being numerical is a different 
> > matter.
> 
>  Wait, what? Are you trying to get it, or set it? Why would you want to
>  edit that?
> >>>
> >>> As Brad has already pointed out, "[…] [testing] will get the official
> >>> release number 10 when buster becomes the stable branch of Debian."
> >>> That's been policy AIUI at least since Debian 1.0 was not released.
> >>> Meanwhile this question is asked, answered, and (re)submitted as a bug.
> >>>
> >>> What seems to be lost on people who feel a pressing need for
> >>> /etc/debian_version to contain a number to satisfy some script that
> >>> they have written (which seems to be the usual reason) is that
> >>> /etc/debian_version is a configuration file. Look in the
> >>> .deb file and there it is, along with /etc/issue{,.net} which
> >>> determine how you are greeted {locally,remotely}. So admins are
> >>> free to set them all how they like.
> >>
> >> I accept that you _can_ edit it. I just don't see why you'd want to,
> > 
> > I can only refer you to a recent iteration of bug reporting:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866885
> > 
> >> especially in terms of the OP's request to find out what the version
> >> number is. If the file has the version number, fine. If not, changing
> >> the file still isn't going to help.
> > 
> > Eh? If the OP wants a version number, then changing the string to a
> > number will help.
> 
> Equally, if I want to know what the time is, I can ask you.
> If you don't know, I can tell you.
> Then I can ask you, and now you'll know, and I'll find out.
> 
> Right?

That's a false analogy. For the time of day, there's only one correct
answer. When software interrogates the clock to find out what the
time is, it's an error for the clock to respond with a different time.

> We must be looking at different problems.
> 
> I'm assuming that if you're trying to look up the version number, it's
> because you don't know what it is.

The *software* that makes the enquiry doesn't know the version number,
so it reads debian_version to find out. On my systems (and most
others) the string in debian_version was chosen by the Debian release
managers in line with Debian policy.

If you've used Debian a long time, you'll know that there were nine
releases before Debian settled on increasing the version number by 1
for each release. (And if you've used TeX, you'll be familiar with
the version number approaching π from below by appending a digit.)

IOW the string is arbitrary. A sysadmin could override the release
managers' choice, and decide to add one to the version number every
time   apt-get upgrade   made any change to the package list. Seems
logical: each upgrade produces a different version of the system.

Cheers,
David.



Re: Debian testing - release number

2018-07-05 Thread Greg Wooledge
On Wed, Jul 04, 2018 at 10:09:29AM -0500, David Wright wrote:
> On Wed 04 Jul 2018 at 09:55:54 (+0900), John Crawley wrote:
> > Sorry, but I thought a "configuration file" was supposed to
> > influence the behaviour of _software_ in some way. Are files which
> > only provide info for humans also considered configuration files?
> 
> Self-evidently, unless you can determine which software is being
> influenced by /etc/{debian_version,issue,issue.net}.

It's a safe bet that there are third-party shell scripts out there which
read /etc/debian_version to make decisions about what commands to use.
I can't point to one at the moment, but there's gotta be a few out there
somewhere.



Re: Debian testing - release number

2018-07-05 Thread Curt
On 2018-07-05, Joe  wrote:
> On Thu, 5 Jul 2018 10:09:36 + (UTC)
> Curt  wrote:
>
>
>> 
>> The problem I'm looking at is that the Debian testing/unstable
>> releases do not have a version number and are not going to be
>> receiving one any time soon (the tradition of not according a number
>> to these two releases being of the utmost venerability). 
>
> How can they? They are never released, and unstable receives new
> software, sometimes new software *versions*, minute by minute. I don't
> know how much new code unstable gets per day, but my workstation
> installation typically downloads something of the order of 50MB,
> usually dozens of packages. Testing is a bit more stable, but
> outside the freeze, basically follows unstable with about ten days'
> delay for a given package. In that context, what can 'release number'
> mean? It can only make sense for stable.
>
Right; I'm not asking for one; I was referring to what you snipped both
above and below.



Re: Debian testing - release number

2018-07-05 Thread Joe
On Thu, 5 Jul 2018 10:09:36 + (UTC)
Curt  wrote:


> 
> The problem I'm looking at is that the Debian testing/unstable
> releases do not have a version number and are not going to be
> receiving one any time soon (the tradition of not according a number
> to these two releases being of the utmost venerability). 

How can they? They are never released, and unstable receives new
software, sometimes new software *versions*, minute by minute. I don't
know how much new code unstable gets per day, but my workstation
installation typically downloads something of the order of 50MB,
usually dozens of packages. Testing is a bit more stable, but
outside the freeze, basically follows unstable with about ten days'
delay for a given package. In that context, what can 'release number'
mean? It can only make sense for stable.

-- 
Joe



Re: Debian testing - release number

2018-07-05 Thread Curt
On 2018-07-05, Richard Hector  wrote:
>
> Equally, if I want to know what the time is, I can ask you.
> If you don't know, I can tell you.
> Then I can ask you, and now you'll know, and I'll find out.
>
> Right?
>
> We must be looking at different problems.
>
> I'm assuming that if you're trying to look up the version number, it's
> because you don't know what it is.

The problem I'm looking at is that the Debian testing/unstable releases
do not have a version number and are not going to be receiving one any
time soon (the tradition of not according a number to these two releases
being of the utmost venerability). This is I gleaned from the bug report
to which DW pointed. As mentioned in the latter the canny and agile
system administrator running testing, for instance, can palliate the
absence of a number by sticking one of his or her liking (10!) in or up
any configuration wazoo he or she finds copacetic, and most notably in
our current context '/etc/debian_version'.


> Richard
>
>



Re: Debian testing - release number

2018-07-04 Thread John Crawley

On 2018-07-05 09:58, Richard Hector wrote:

On 05/07/18 03:53, David Wright wrote:

On Wed 04 Jul 2018 at 13:18:14 (+1200), Richard Hector wrote:

On 02/07/18 05:31, David Wright wrote:

On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:

On 28/06/18 16:40, David Wright wrote:

On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:

I am wondering if it is possible to get the debian release number
for debian testing (and maybe sid) from command line?

Yes.
# cat > /etc/debian_version
Write whatever you want here
Whether it's advisable to depend on its being numerical is a different matter.


Wait, what? Are you trying to get it, or set it? Why would you want to
edit that?


As Brad has already pointed out, "[…] [testing] will get the official
release number 10 when buster becomes the stable branch of Debian."
That's been policy AIUI at least since Debian 1.0 was not released.
What seems to be lost on people who feel a pressing need for
/etc/debian_version to contain a number to satisfy some script that
they have written (which seems to be the usual reason) is that
/etc/debian_version is a configuration file. Look in the
.deb file and there it is, along with /etc/issue{,.net} which
determine how you are greeted {locally,remotely}. So admins are
free to set them all how they like.


I accept that you _can_ edit it. I just don't see why you'd want to,


I can only refer you to a recent iteration of bug reporting:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866885


especially in terms of the OP's request to find out what the version
number is. If the file has the version number, fine. If not, changing
the file still isn't going to help.


Eh? If the OP wants a version number, then changing the string to a
number will help.


Equally, if I want to know what the time is, I can ask you.
If you don't know, I can tell you.
Then I can ask you, and now you'll know, and I'll find out.

Right?

We must be looking at different problems.

I'm assuming that if you're trying to look up the version number, it's
because you don't know what it is.


It would be relatively simple to make a script which read the words in 
/etc/debian_version, performed a mapping to some number and appended the 
result to that file. However Debian policy here implies that a version 
number _has_no_meaning_ until a release is made. You could still go 
ahead and add one, if it would save whatever scripts wanted that info 
from having to do the above mapping themselves, but there's no guarantee 
outside that sysadmin's domain of what such a number would mean.


--
John



Re: Debian testing - release number

2018-07-04 Thread Richard Hector
On 05/07/18 03:53, David Wright wrote:
> On Wed 04 Jul 2018 at 13:18:14 (+1200), Richard Hector wrote:
>> On 02/07/18 05:31, David Wright wrote:
>>> On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:
 On 28/06/18 16:40, David Wright wrote:
> On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
>> I am wondering if it is possible to get the debian release number
>> for debian testing (and maybe sid) from command line?
>
> Yes.
>
> # cat > /etc/debian_version
> Write whatever you want here
> ^D
>
> Job done. (That's a control-D.)
>
> Whether it's advisable to depend on its being numerical is a different 
> matter.

 Wait, what? Are you trying to get it, or set it? Why would you want to
 edit that?
>>>
>>> As Brad has already pointed out, "[…] [testing] will get the official
>>> release number 10 when buster becomes the stable branch of Debian."
>>> That's been policy AIUI at least since Debian 1.0 was not released.
>>> Meanwhile this question is asked, answered, and (re)submitted as a bug.
>>>
>>> What seems to be lost on people who feel a pressing need for
>>> /etc/debian_version to contain a number to satisfy some script that
>>> they have written (which seems to be the usual reason) is that
>>> /etc/debian_version is a configuration file. Look in the
>>> .deb file and there it is, along with /etc/issue{,.net} which
>>> determine how you are greeted {locally,remotely}. So admins are
>>> free to set them all how they like.
>>
>> I accept that you _can_ edit it. I just don't see why you'd want to,
> 
> I can only refer you to a recent iteration of bug reporting:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866885
> 
>> especially in terms of the OP's request to find out what the version
>> number is. If the file has the version number, fine. If not, changing
>> the file still isn't going to help.
> 
> Eh? If the OP wants a version number, then changing the string to a
> number will help.

Equally, if I want to know what the time is, I can ask you.
If you don't know, I can tell you.
Then I can ask you, and now you'll know, and I'll find out.

Right?

We must be looking at different problems.

I'm assuming that if you're trying to look up the version number, it's
because you don't know what it is.

Richard



signature.asc
Description: OpenPGP digital signature


Re: Debian testing - release number

2018-07-04 Thread David Wright
On Wed 04 Jul 2018 at 13:18:14 (+1200), Richard Hector wrote:
> On 02/07/18 05:31, David Wright wrote:
> > On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:
> >> On 28/06/18 16:40, David Wright wrote:
> >>> On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
>  I am wondering if it is possible to get the debian release number
>  for debian testing (and maybe sid) from command line?
> >>>
> >>> Yes.
> >>>
> >>> # cat > /etc/debian_version
> >>> Write whatever you want here
> >>> ^D
> >>>
> >>> Job done. (That's a control-D.)
> >>>
> >>> Whether it's advisable to depend on its being numerical is a different 
> >>> matter.
> >>
> >> Wait, what? Are you trying to get it, or set it? Why would you want to
> >> edit that?
> > 
> > As Brad has already pointed out, "[…] [testing] will get the official
> > release number 10 when buster becomes the stable branch of Debian."
> > That's been policy AIUI at least since Debian 1.0 was not released.
> > Meanwhile this question is asked, answered, and (re)submitted as a bug.
> > 
> > What seems to be lost on people who feel a pressing need for
> > /etc/debian_version to contain a number to satisfy some script that
> > they have written (which seems to be the usual reason) is that
> > /etc/debian_version is a configuration file. Look in the
> > .deb file and there it is, along with /etc/issue{,.net} which
> > determine how you are greeted {locally,remotely}. So admins are
> > free to set them all how they like.
> 
> I accept that you _can_ edit it. I just don't see why you'd want to,

I can only refer you to a recent iteration of bug reporting:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866885

> especially in terms of the OP's request to find out what the version
> number is. If the file has the version number, fine. If not, changing
> the file still isn't going to help.

Eh? If the OP wants a version number, then changing the string to a
number will help. They could try to predict the upcoming version
(bad idea), or indicate there isn't one with zero, or they could use
a trusty sentinal value like 999 if it was important for the version
number to be > V(stable). I'm not condoning any of these, just
pointing out that the value is within the gift of the sysadmin.

If a sysadmin thinks that debian_version is an important and accurate
indication of the system's state when it's running testing, that
might be a problem.

Cheers,
David.



Re: Debian testing - release number

2018-07-04 Thread David Wright
On Wed 04 Jul 2018 at 09:55:54 (+0900), John Crawley wrote:
> On 2018-07-02 02:31, David Wright wrote:
> >What seems to be lost on people who feel a pressing need for
> >/etc/debian_version to contain a number to satisfy some script that
> >they have written (which seems to be the usual reason) is that
> >/etc/debian_version is a configuration file.
> 
> >I don't know of and wouldn't expect the value to be
> >of any use to the system configuration tools, only to humans.
> 
> Sorry, but I thought a "configuration file" was supposed to
> influence the behaviour of _software_ in some way. Are files which
> only provide info for humans also considered configuration files?

Self-evidently, unless you can determine which software is being
influenced by /etc/{debian_version,issue,issue.net}. You might
say report-bug, but all that does is copy it for perusal by
other people, hence my caveat (that you snipped in the above).

> If
> a sysadmin edited the contents of /etc/debian_version what other
> human would be expected to benefit?

Obviously anyone who runs software that the sysadmin deems to be
influenced by its contents, and which led to its being changed.

Cheers,
David.



Re: Debian testing - release number

2018-07-03 Thread Richard Hector
On 02/07/18 05:31, David Wright wrote:
> On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:
>> On 28/06/18 16:40, David Wright wrote:
>>> On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
 I am wondering if it is possible to get the debian release number
 for debian testing (and maybe sid) from command line?
>>>
>>> Yes.
>>>
>>> # cat > /etc/debian_version
>>> Write whatever you want here
>>> ^D
>>>
>>> Job done. (That's a control-D.)
>>>
>>> Whether it's advisable to depend on its being numerical is a different 
>>> matter.
>>
>> Wait, what? Are you trying to get it, or set it? Why would you want to
>> edit that?
> 
> As Brad has already pointed out, "[…] [testing] will get the official
> release number 10 when buster becomes the stable branch of Debian."
> That's been policy AIUI at least since Debian 1.0 was not released.
> Meanwhile this question is asked, answered, and (re)submitted as a bug.
> 
> What seems to be lost on people who feel a pressing need for
> /etc/debian_version to contain a number to satisfy some script that
> they have written (which seems to be the usual reason) is that
> /etc/debian_version is a configuration file. Look in the
> .deb file and there it is, along with /etc/issue{,.net} which
> determine how you are greeted {locally,remotely}. So admins are
> free to set them all how they like.

I accept that you _can_ edit it. I just don't see why you'd want to,
especially in terms of the OP's request to find out what the version
number is. If the file has the version number, fine. If not, changing
the file still isn't going to help.

Richard




signature.asc
Description: OpenPGP digital signature


Re: Debian testing - release number

2018-07-03 Thread John Crawley

On 2018-07-02 02:31, David Wright wrote:

What seems to be lost on people who feel a pressing need for
/etc/debian_version to contain a number to satisfy some script that
they have written (which seems to be the usual reason) is that
/etc/debian_version is a configuration file. 



I don't know of and wouldn't expect the value to be
of any use to the system configuration tools, only to humans.


Sorry, but I thought a "configuration file" was supposed to influence 
the behaviour of _software_ in some way. Are files which only provide 
info for humans also considered configuration files? If a sysadmin 
edited the contents of /etc/debian_version what other human would be 
expected to benefit?


--
John



Re: Debian testing - release number

2018-07-01 Thread David Wright
On Sun 01 Jul 2018 at 22:44:17 (+1200), Richard Hector wrote:
> On 28/06/18 16:40, David Wright wrote:
> > On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
> >> I am wondering if it is possible to get the debian release number
> >> for debian testing (and maybe sid) from command line?
> > 
> > Yes.
> > 
> > # cat > /etc/debian_version
> > Write whatever you want here
> > ^D
> > 
> > Job done. (That's a control-D.)
> > 
> > Whether it's advisable to depend on its being numerical is a different 
> > matter.
> 
> Wait, what? Are you trying to get it, or set it? Why would you want to
> edit that?

As Brad has already pointed out, "[…] [testing] will get the official
release number 10 when buster becomes the stable branch of Debian."
That's been policy AIUI at least since Debian 1.0 was not released.
Meanwhile this question is asked, answered, and (re)submitted as a bug.

What seems to be lost on people who feel a pressing need for
/etc/debian_version to contain a number to satisfy some script that
they have written (which seems to be the usual reason) is that
/etc/debian_version is a configuration file. Look in the
.deb file and there it is, along with /etc/issue{,.net} which
determine how you are greeted {locally,remotely}. So admins are
free to set them all how they like.

Of course, there's no use then in quoting it in support of bug
reports etc. I don't know of and wouldn't expect the value to be
of any use to the system configuration tools, only to humans.

Cheers,
David.



Re: Debian testing - release number

2018-07-01 Thread Richard Hector
On 28/06/18 16:40, David Wright wrote:
> On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
>> I am wondering if it is possible to get the debian release number
>> for debian testing (and maybe sid) from command line?
> 
> Yes.
> 
> # cat > /etc/debian_version
> Write whatever you want here
> ^D
> 
> Job done. (That's a control-D.)
> 
> Whether it's advisable to depend on its being numerical is a different matter.

Wait, what? Are you trying to get it, or set it? Why would you want to
edit that?

Richard



signature.asc
Description: OpenPGP digital signature


Re: Debian testing - release number

2018-06-27 Thread David Wright
On Wed 27 Jun 2018 at 19:49:13 (+0200), Martin Krämer wrote:
> I am wondering if it is possible to get the debian release number
> for debian testing (and maybe sid) from command line?

Yes.

# cat > /etc/debian_version
Write whatever you want here
^D

Job done. (That's a control-D.)

Whether it's advisable to depend on its being numerical is a different matter.

Cheers,
David.



Re: Debian testing - release number

2018-06-27 Thread Roberto C . Sánchez
On Wed, Jun 27, 2018 at 03:03:45PM -0500, Nicholas Geovanis wrote:
> On Wed, Jun 27, 2018 at 12:49 PM Martin Krämer  wrote:
> >
> > I am wondering if it is possible to get the debian release number for 
> > debian testing (and maybe sid) from command line?
> > I know that current testing is codename buster, while its release number is 
> > 10.
> > I can get the codename from command line, but not that the corresponding 
> > release number is 10. I know I could match the codename to release numbers, 
> > but that is not a nice solution.
> > For stable (stretch 9) and oldstable (jessie 8) etc. it is possible to get 
> > that number using different commands.
> >
> > I additionally understand that it is not possible to display something like 
> > 10.1 or 10.2 since testing follows not the same release process as stable 
> > does.
> >
> > Here are the commands & output I tested without success:
> > 
> .
> > root@mybuster:~# cat /etc/debian_version
> > buster/sid
> 
> Interesting. Even 9.2 and 9.3 servers installed here contain the following:
> 
> ngeovanis@maglab01:~$ cat /etc/debian_version
> 9.2
> ngeovanis@maglab01:~$
> > Thank you for any input :)
> 

That is because buster is still development, so it is not yet released.
It would not make much sense to have it report a release version, since
the assigned version is still just a planned version at this point.

Regards,

-Roberto

-- 
Roberto C. Sánchez



Re: Debian testing - release number

2018-06-27 Thread Nicholas Geovanis
On Wed, Jun 27, 2018 at 12:49 PM Martin Krämer  wrote:
>
> I am wondering if it is possible to get the debian release number for debian 
> testing (and maybe sid) from command line?
> I know that current testing is codename buster, while its release number is 
> 10.
> I can get the codename from command line, but not that the corresponding 
> release number is 10. I know I could match the codename to release numbers, 
> but that is not a nice solution.
> For stable (stretch 9) and oldstable (jessie 8) etc. it is possible to get 
> that number using different commands.
>
> I additionally understand that it is not possible to display something like 
> 10.1 or 10.2 since testing follows not the same release process as stable 
> does.
>
> Here are the commands & output I tested without success:
> 
.
> root@mybuster:~# cat /etc/debian_version
> buster/sid

Interesting. Even 9.2 and 9.3 servers installed here contain the following:

ngeovanis@maglab01:~$ cat /etc/debian_version
9.2
ngeovanis@maglab01:~$
> Thank you for any input :)



Re: Debian testing - release number

2018-06-27 Thread Brad Rogers
On Wed, 27 Jun 2018 19:49:13 +0200
Martin Krämer  wrote:

Hello Martin,

>I know that current testing is codename buster, while its release
>number is 10.

My (possibly mistaken) understanding is that it will get the official
release number 10 when buster becomes the stable branch of Debian.

See https://wiki.debian.org/DebianReleases which indicates v10/buster
has no release date yet.  IOW it will be at some, currently unknown, time
in the future.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Where will you be when the bodies burn?
The Gasman Cometh - Crass


pgpzY35WgU1hv.pgp
Description: OpenPGP digital signature