Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #196986 > unrolled thread

Re: Debian testing - release number

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-06-28 06:50 +0200
    Re: Debian testing - release number Richard Hector <richard@walnut.gen.nz> - 2018-07-01 12:50 +0200
      Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-01 19:40 +0200
        Re: Debian testing - release number John Crawley <john@bunsenlabs.org> - 2018-07-04 03:00 +0200
          Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-04 17:20 +0200
            Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-05 14:20 +0200
        Re: Debian testing - release number Richard Hector <richard@walnut.gen.nz> - 2018-07-04 03:20 +0200
          Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-04 18:00 +0200
            Re: Debian testing - release number Richard Hector <richard@walnut.gen.nz> - 2018-07-05 03:00 +0200
              Re: Debian testing - release number John Crawley <john@bunsenlabs.org> - 2018-07-05 04:20 +0200
              Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-05 12:20 +0200
                Re: Debian testing - release number Joe <joe@jretrading.com> - 2018-07-05 13:00 +0200
                  Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-05 13:50 +0200
                  Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-05 18:10 +0200
                    Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-05 18:50 +0200
                      Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-05 20:00 +0200
                        Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-05 20:10 +0200
                          Re: Debian testing - release number Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-07-05 22:00 +0200
                            Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-05 22:20 +0200
                              Re: Debian testing - release number Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-07-05 22:30 +0200
                                Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-05 22:50 +0200
                                  Re: Debian testing - release number Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-07-05 23:40 +0200
                                    Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-06 02:10 +0200
                                    Re: Debian testing - release number The Wanderer <wanderer@fastmail.fm> - 2018-07-06 19:00 +0200
                                      Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-06 20:10 +0200
                            Re: Debian testing - release number Joe <joe@jretrading.com> - 2018-07-05 22:40 +0200
                          Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-06 02:20 +0200
                            Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-06 10:50 +0200
                              Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-06 14:10 +0200
                                Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-06 15:10 +0200
                                  Re: Debian testing - release number davidson <davidson@freevolt.org> - 2018-07-07 06:10 +0200
                                    Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-07 10:00 +0200
                                      Re: Debian testing - release number Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-09 15:00 +0200
                                        Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-09 17:30 +0200
                              Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-10 23:30 +0200
                                Re: Debian testing - release number Curt <curty@free.fr> - 2018-07-11 14:00 +0200
                                  Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-13 21:20 +0200
              Re: Debian testing - release number David Wright <deblis@lionunicorn.co.uk> - 2018-07-05 16:50 +0200

Page 1 of 2  [1] 2  Next page →

#196986 — Re: Debian testing - release number

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.

[toc] | [next] | [standalone]

#197079

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#197091

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.

[toc] | [prev] | [next] | [standalone]

#197181

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

[toc] | [prev] | [next] | [standalone]

#197198

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.

[toc] | [prev] | [next] | [standalone]

#197223

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.

[toc] | [prev] | [next] | [standalone]

#197182

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#197199

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.

[toc] | [prev] | [next] | [standalone]

#197212

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#197214

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

[toc] | [prev] | [next] | [standalone]

#197220

On 2018-07-05, Richard Hector <richard@walnut.gen.nz> 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
>
>

[toc] | [prev] | [next] | [standalone]

#197221

On Thu, 5 Jul 2018 10:09:36 +0000 (UTC)
Curt <curty@free.fr> 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

[toc] | [prev] | [next] | [standalone]

#197222

On 2018-07-05, Joe <joe@jretrading.com> wrote:
> On Thu, 5 Jul 2018 10:09:36 +0000 (UTC)
> Curt <curty@free.fr> 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.

[toc] | [prev] | [next] | [standalone]

#197233

On Thu 05 Jul 2018 at 11:53:45 (+0100), Joe wrote:
> On Thu, 5 Jul 2018 10:09:36 +0000 (UTC)
> Curt <curty@free.fr> 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.

[toc] | [prev] | [next] | [standalone]

#197236

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).

[toc] | [prev] | [next] | [standalone]

#197237

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.

[toc] | [prev] | [next] | [standalone]

#197239

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.

[toc] | [prev] | [next] | [standalone]

#197241

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 <wooledg@eeg.ccf.org> 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.
>

[toc] | [prev] | [next] | [standalone]

#197242

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 fuuuuture {probably just abort} ;;
  9.*)        : code to handle stretch ;;
  8.*)        : code to handle jessie ;;
  *)          : code to handle "too old" or "unknown" {probably just abort} ;;
esac

[toc] | [prev] | [next] | [standalone]

#197243

On Thu, Jul 5, 2018 at 3:16 PM Greg Wooledge <wooledg@eeg.ccf.org> 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...... :-)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web