On 2018-04-13 22:17, Ralf Lang wrote:

Am 13.04.2018 um 21:40 schrieb David C. Rankin:

...

All,

This is an oddity that has broken some configuration scripts of mine. For the first time since 7.0 (Air), there is no /etc/SuSE-release. I don't know if this is intentional or not. There is an /etc/os-release present. A simple softlink will correct the problem.

While probably not common, the lack of /etc/SuSE-release has causes problem in my .bashrc where there are conditionals for configuration depending on the os installed., e.g.

if test -e "/etc/SuSE-release" then ... else if test -e "/etc/arch-release" then ...

I don't know the reason it's not included, maybe it's due to the Beta status, but it may be something to consider restoring so that others aren't caught by surprise. I can just symlink it, or parse the output of os-release, but providing the link would continue two-decades of consistency.

That's most likely intentional, SLE15 also does not have this file anymore.  /etc/os-release has been the way to go for years now, it's cross-distro and you should really move/change your scripts now at the very latest.

But being cross-distro means that it has to be parsed to get the equivalent result to detecting the presence of SuSE-release -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-04-13 22:59, Brüns, Stefan wrote:

On Freitag, 13. April 2018 22:50:24 CEST Carlos E. R. wrote:

...

On 2018-04-13 22:17, Ralf Lang wrote:

...

Am 13.04.2018 um 21:40 schrieb David C. Rankin:

...

...

That's most likely intentional, SLE15 also does not have this file anymore. /etc/os-release has been the way to go for years now, it's cross-distro and you should really move/change your scripts now at the very latest.

But being cross-distro means that it has to be parsed to get the equivalent result to detecting the presence of SuSE-release

if grep -q 'ID_LIKE="suse"' /etc/os-release ; then echo "Geeko found!" fi

#!/bin/bash . /etc/os-release #... if [ $ID_LIKE -n ] ; then echo "Geeko found!" fi In his case, rather do a "case $ID_LIKE in" to cover several distros. Or perhaps use "ID" instead. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

El 13-04-2018 a las 18:21, Brüns, Stefan escribió:

Someone should create a distribution called `rm -Rf $HOME` ...

or just "init 0" to increase hair loss.. :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2018-04-13 23:18, Cristian Rodríguez wrote:

El 13-04-2018 a las 16:40, David C. Rankin escribió:

...

A simple softlink will correct the problem.

No, SuSE-release predates de-facto standard os-release by a very long time and does not have the same contents or format.

He doesn't parse the file, just detects its presence. For his use case it would be enough to touch the file to create it (0 bytes), and later change his scripts to parse os-release instead, with the added benefit that would work with most distros with the same code. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-04-13 23:37, Cristian Rodríguez wrote:

El 13-04-2018 a las 18:22, Carlos E. R. escribió:

...

He doesn't parse the file, just detects its presence.

Yes, he doesn't.. however other software does behind his back.."if suse release found then parse else read os-release.."

(grumble) How things get complicated... You are right, if there are other apps that try to parse that old file they will find the wrong contents (symlinked or touched file) and fail in unpredicted ways. David: don't symlink the file. Don't create it with zero bytes. As a temporary hack, create the file yourself with /correct/ contents: openSUSE 15.0 (x86_64) VERSION = 15.0 CODENAME = Dunno # /etc/SuSE-release is deprecated and will be removed in the future... And take that time to correct your scripts. No other way. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/15/2018 08:59 AM, David C. Rankin wrote:

On 04/13/2018 05:44 PM, Carlos E. R. wrote:

...

David: don't symlink the file. Don't create it with zero bytes. As a temporary hack, create the file yourself with /correct/ contents:

openSUSE 15.0 (x86_64) VERSION = 15.0 CODENAME = Dunno # /etc/SuSE-release is deprecated and will be removed in the future...

And take that time to correct your scripts. No other way.

Will do. Parsing os-release is no problem (thank you and Bengt for the suggestions).

I think I'll go with: osrel=$(sed -n '/^ID=/s/^.*=//p' /etc/os-release); and then if test "$osrel" = "opensuse" then ... elseif test "$osrel" = "arch" then ... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/15/2018 10:40 AM, Per Jessen wrote:

Just wondering why you woulnd't source it, and evaluate the variables directly?

. /etc/os-release if test "$ID" = "opensuse" then ... elseif test "$ID" = "arch" then ...

I generally don't source anything I didn't create or have control over the contents of in my startup scripts. I also try and remain POSIX shell compliant. It's just personal preference. It could be sourced, but then unless I check the file on each update, I don't know if there are any new potentially conflicting names that may get pulled in. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/15/2018 11:34 AM, Carlos E. R. wrote:

But this file was designed to be simply sourced. It is faster than running grep or sed on it.

So was SuSE-release -- but it disappeared :( -- David C. Rankin, J.D.,P.E.

Hello, a generic addedum: On Apr 16 11:39 Richard Brown wrote (excerpt):

SuSE-release contained the following information for almost_FIVE_YEARS_ (Since Nov 2013)

"# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead"

From the user's point of view things may look different:

Assume 'the user' is a 'normal end-user': Then he probably never had read the content of the file that got now removed, i.e. a 'normal end-user' may not know about the deprecation info (regardless how long it was there). What happens for a 'normal end-user' when that file got finally actually removed is that "something else" does no longer work and that is what a 'normal end-user' recognizes. Now with some 'normal end-user' debugging he may even find out that a particular file does no longer exist and complain about that. Unfortunately 'normal end-users' too often complain instead of only describing their particular issue, cf. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html Assume 'the user' is a developer of that "something else": Even the developers of that "something else" software may never read that deprecation info because as long as their "something else" works there is nothing that indicates in an obvious way that a deprecation issue is lurking around. Simply put: In general deprecation info does not work in practice. In theory, theory and practice are the same. In practice, they are not. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

On Monday, 2018-04-16 at 13:03 +0200, Johannes Meixner wrote:

...

...

Unfortunately 'normal end-users' too often complain instead of only describing their particular issue, cf. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I like this article. Would it be a good idea to link it on the wiki? Perhaps on https://en.opensuse.org/openSUSE:Bug_reporting_FAQ

Yes, why not. It's a bit more elaborate than ESRs "how to ask questions the smart way". -- Per Jessen, Zürich (13.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2018-04-17 11:06, Joachim Wagner wrote:

...

...

I like this article. Would it be a good idea to link it on the wiki? Perhaps on https://en.opensuse.org/openSUSE:Bug_reporting_FAQ

Yes, why not. It's a bit more elaborate than ESRs "how to ask questions the smart way".

Done. New section "further reading" under "1 What kind of feedback do you want?".

Good! you beat me to it ;-)

Also added 2.7 Why is my report "XYZ doesn't work" not taken serious? @native speakers here: should this be "seriously"?

Non native here thinks it is seriously. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 04/17/2018 11:25 AM, ne... wrote:

On 17 April 2018 at 10:06, Joachim Wagner wrote:

...

Also added 2.7 Why is my report "XYZ doesn't work" not taken serious? @native speakers here: should this be "seriously"? Yes.

Regards...

Unless of course, you feel compelled to "Think Different" Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/16/2018 04:39 AM, Richard Brown wrote:

...

...

But this file was designed to be simply sourced. It is faster than running grep or sed on it. So was SuSE-release -- but it disappeared :( SuSE-release contained the following information for almost_FIVE YEARS_ (Since Nov 2013)

"# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead"

This notice has been carried in every single openSUSE release since (and including) 13.1

4 years is more than enough notice for a deprecation warning, can you please stop complaining?

You miss the point. It's not a complaint. Don't re-characterize it as such. It was a curiosity. While there was no mystery that SuSE-release would go away at some point -- the point was Why now? As you, it had carried a notice since 13.1, e.g. 14:42 alchemy:~> cat /etc/SuSE-release openSUSE 13.1 (x86_64) VERSION = 13.1 CODENAME = Bottle # /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead So we have a deprecation notice of removal and some unspecified date in the future. So then 13.2 comes and goes, along with 42.1, 42.2, 42.3, all containing the same notice. Thus the curiosity -- why now? The move to os-release has been resolved, but that leaves unanswered the import of dropping it with 15. I don't disagree with dropping it, I merely posed the question of whether it made sense to continue to carry it for the very reason that cropped up here. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/04/18 05:16, David C. Rankin wrote:

So we have a deprecation notice of removal and some unspecified date in the future. So then 13.2 comes and goes, along with 42.1, 42.2, 42.3, all containing the same notice. Thus the curiosity -- why now?

This likely has a simple answer, 42.X was based off and 13.2 was created at a similar time to SUSE Linux Enterprise 12 (Released Oct 2014), I can't be bothered looking if the file was already deprecated in SLE 11 but as we come up to the release of SLE / Leap 15 it is the perfect time to remove things that were deprecated in the past. In a similar way over the last 6 months there has also been a package clean up and a bunch of packages that we no longer wish to maintain have been dropped from tumbleweed. In short the time before a new major release is the perfect time for a bit of "spring cleaning" -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 14 Apr 2018 00:44:59 +0200 "Carlos E. R." wrote:

David: don't symlink the file. Don't create it with zero bytes. As a temporary hack, create the file yourself with /correct/ contents:

openSUSE 15.0 (x86_64) VERSION = 15.0 CODENAME = Dunno # /etc/SuSE-release is deprecated and will be removed in the future...

And take that time to correct your scripts. No other way.

That looks quite close to the contents of the /etc/SUSE-brand file. Is checking for that instead useful? -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2018-04-16 at 10:47 +0200, Ludwig Nussel wrote:

David C. Rankin wrote:

...

This is an oddity that has broken some configuration scripts of mine. For the first time since 7.0 (Air), there is no /etc/SuSE-release. I don't know if this is intentional or not. There is an /etc/os-release present. A simple softlink will correct the problem.

As others have pointed out this is intentional. Since you tripped over it, mind filing a bug against release nots to document this?

Re: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/index.html There is a click on the top right to start bugzilla prefilled ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrUo4YACgkQtTMYHG2NR9V9ZgCgkCgC2Qo7yP0+ckJdvyZV/PBY mTEAn2nsvpzs+n/vcJkpQrDLoi/O82Sz =LsNX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello! Thanks for creating such wiki-page. Also cross-linking between https://en.opensuse.org/Etc_SuSE-release and https://en.opensuse.org/SDB:SUSE_and_openSUSE_Products_Version_Outputs wiki-pages is added. 17 апреля 2018 г. 13:39:24 GMT+03:00, Joachim Wagner пишет:

...

The wiki page

https://en.opensuse.org/SDB:SUSE_and_openSUSE_Products_Version_Outputs

...

has some content about os-release. It needs some cleanup and it would probably be a good idea to put some simple(!) shell code there that does the job of parsing ID_LIKE in a sufficient way.

This wiki page is not in the first 20 results when I search for /etc/SuSE- release on google. To more prominently mention /etc/SuSE-release on the wiki so that people encountering problems with the removal of the file are more likely to find information about it, I created https://en.opensuse.org/ Etc_SuSE-release .

Note there's also a page https://en.opensuse.org/SDB:Find_openSUSE_version

Still, there is the issue of software that fails silently or with no useful error message because of the removed file.

Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Apr 16 13:41 Bruno Friedmann wrote (excerpt):

Perhaps it is time to have a look at the nice tool lsb_release and what it can achieve for you

a nice tool can only achieve something if it is installed. Gets lsb_release installed in any case? In case of doubt try "rpm -e --test lsb-release". If that succeeds it is not required which means the nice tool lsb_release may not be installed. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Thorsten, On Mon, 16 Apr 2018, 16:55:46 +0200, Thorsten Kukuk wrote:

[...] "rpm -e --test kernel-default"

Hm, the kernel is not required, which means it may not be installed.

if that's actually the case, I'd call this a bug! We all know, a "kernel" is *required*, hence it should be Require'd by some rpm or by all base patterns! BTW, I get a lot of error messages about "Failed dependencies" when trying to test-remove kernel-default...

If you need a tool, either you require it in your package, or you need to find another way to make sure it gets installed.

Exactly. At least the kernel should be on the safe side and not being installed by accident... ;)

Thorsten

Cheers. l8er manfred

On 17/04/18 18:57, Johannes Meixner wrote:

Hello,

On Apr 16 16:55 Thorsten Kukuk wrote (excerpt):

...

On Mon, Apr 16, Johannes Meixner wrote:

...

In case of doubt try "rpm -e --test lsb-release". If that succeeds it is not required which means the nice tool lsb_release may not be installed.

"rpm -e --test kernel-default"

Hm, the kernel is not required, which means it may not be installed.

E.g. inside Linux containers - so what? What do you like to tell here?

A side note:

When one installs a normal SUSE system on plain command line (in inst-sys) one will notice that no kernel RPM is required, cf. "Generic system installation with the plain SUSE installation system" in https://en.opensuse.org/SDB:Disaster_Recovery

Its also technically not required from the openSUSE installer, if you select other then unselect everything other then "Minimal_Base" (atleast I hope we disabled unselecting that) you may well also get a system without a kernel but I didn't try that yet. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org