LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-22-2012, 02:07 PM   #46
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761

Quote:
Originally Posted by FeyFre View Post
ruario, since You maintaining Opera next packages for Slackware You are free to generate packages which will create os-release file(or don't touch it if it exists) and fill it with proper information(in doinst.sh).
Actually no I cannot do that, if the os-release file is not present how will Opera create a valid one? Or to put it another way, if I knew a good way to detect the distro well enough that I could create one on the fly, I wouldn't need the file in the first place. It is a "chicken and egg" problem.

In addition, I actually think it would be a horrible idea if Opera created files that have nothing to do with Opera.
 
1 members found this post helpful.
Old 08-22-2012, 03:36 PM   #47
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105
Quote:
Originally Posted by FeyFre View Post
ruario, since You maintaining Opera next packages for Slackware You are free to generate packages which will create os-release file(or don't touch it if it exists) and fill it with proper information(in doinst.sh). (As far as I understood most bug-rich releases is -next snapshots so it is more important to support feature You requested in snapshot builds than in releases). Also You can try to convince Opera Slackbuild maintainer at SBo to do the same. It will not break anything in Slackware(because nothing relays on it) but will help Opera. And if/when mr.Volkerding will decide to introduce os-release all you have to do is rollback doinst.sh.
By the way, You(or specified maintainer) can do that for other packages types(deb, rpms) - teach post-install step to (re)generate os-release file(or some other file from where Opera browser can gather information - Opera will become more independent from 3rd-party decisions).
That is a bold statement if I ever saw one... A Slackware package should never ever try to install non-related and OS-owned files.

Eric
 
Old 08-22-2012, 05:15 PM   #48
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 351

Rep: Reputation: 30
Quote:
if the os-release file is not present how will Opera create a valid one?
Quote:
Originally Posted by ruario
if I knew a good way to detect the distro well enough that I could create one on the fly
Not Opera, but SlackBuild for Opera. By definition packages built by SlackBuilds are intended to be used in Slackware and its heirs(sorry, derivatives), so doints.sh in those packages have 100% guarantee that it will be executed in Slackware environment. I have read os-release file specification. My conclusion - its content can be generated on fly by any piece of software unless restriction to read /etc/*
Quote:
In addition, I actually think it would be a horrible idea if Opera created files that have nothing to do with Opera.
As I already said, not Opera creates but Installer. Why nothing? Opera is going to use it directly(not via 3rd-party library), right? Right.
If You so fear to interact with /etc/os-release You can interact with /usr/lib/opera/os-release. You(I mean doinst.sh in Opera package) can put there the same information as in /etc/os-release, and nobody will pretend this file is bad.
Basically I propose You to delegate task of gathering information about environment to distribution-specific installer( .t?z, .rpm, .deb). During installation data will be gathered and stored in Opera-specific path(for instance /usr/lib/opera/os-release). So when Opera crashes it knows that information about environment is stored in that hardcoded path).
 
Old 08-22-2012, 05:53 PM   #49
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 351

Rep: Reputation: 30
Quote:
Originally Posted by Alien Bob View Post
That is a bold statement if I ever saw one... A Slackware package should never ever try to install non-related and OS-owned files.

Eric
Not, this is not.
OS-owned? Where? Did I missed something? Did I missed adoption message like "Yes, /etc/os-release will be included into next/current Slackware release" signed by Mr.Volkerding or smb else authorized to make such statements? Until I see such statement here or elsewhere of what we can thread as reliable source or when /etc/os-release will appear in aaa_base-${VERSION}-${ARCH}${TAG}.txz "/etc/os-release" cannot be treated as "OS-owned". And each and every package have full right to install/create that file. Or there is restriction to all explicitly not enabled packages to put something into /etc ?

Last edited by FeyFre; 08-22-2012 at 06:26 PM. Reason: typo
 
Old 08-22-2012, 06:16 PM   #50
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105
Quote:
Originally Posted by FeyFre View Post
Not, this is not.
OS-owned? Where? Did I missed something? Did I missed adoption message like "Yes, /etc/os-release will be included into next/current Slackware release" signed by Mr.Volkerding or smb else authorized to make such statements? Until I see such statement here or elsewhere of what we can thread as reliable source or when /etc/os-release will appear in aaa_base-${VERSION}-${ARCH}${TAG}.txz "/etc/os-release" cannot be tread as "OS-owned". And each and every package have full right to install/create that file. Or there is restriction to all explicitly not enabled packages to put something into /etc ?
You have a lot to learn yet, young padawan. A file like "/etc/os-release" is in the domain of the distro maintainer and you have no business there.

For sure your reply makes it very clear that I will not touch any of your packages unless after triple-checking.

Eric
 
1 members found this post helpful.
Old 08-22-2012, 06:40 PM   #51
ttk
Senior Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 1,038
Blog Entries: 27

Rep: Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484
Quote:
Originally Posted by volkerdi View Post
I guess the question that comes to my mind, is: If you didn't know enough about a given distribution to detect that you were running on it through the distro-specific file, how are you possibly going to know enough about it to be able to have your software tailor itself for that distribution?
A file like this is often useful for determining what is "out there" in a datacenter environment.

For instance, at my previous employer, the only information which was stored in a central location about the (roughly 20,000) servers was their cluster domains and their IP addresses. There was no easy way to determine what OSes these servers were running, their names, their hardware configuration, etc. This information existed in bits and pieces in files belonging to different individual sysadmins and managers. There was a bastion server for each cluster, though, from which one could ssh to each machine in that cluster.

Using mssh, I was able to first upload my self-id script to each server, and then run self-id on them, getting back a complete list of which servers were running CentOS, RedHat (very old, before it became fc and rhel), or SuSE, which versions, and which architectures. Armed with that information, I could start making plans for the tasks which had been assigned to me.

self-id isn't that complicated of a script (I linked to it in a previous post), but if /etc/os-release were universally adopted, it could have been replaced by a simple "cat /etc/os-release" command (run on each of the servers via mssh).

The assumptions one can safely make in a datacenter context are .. kinda different.

I love Slackware (obviously!), especially for servers, but it isn't always the best fit for datacenter deployment. Adding /etc/os-release would make some people's lives easier.
 
1 members found this post helpful.
Old 08-22-2012, 07:13 PM   #52
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 351

Rep: Reputation: 30
Quote:
For sure your reply makes it very clear that I will not touch any of your packages unless after triple-checking.
I would be happy if at least one user will do triple-checking procedure for any packages. Unconditionally. Including mine. I do it for every package. I always disappointed if somebody trust my(or somebody's else) packages 100% blindly.

PS: Forced to quit this discussion due language barrier.

Last edited by FeyFre; 08-22-2012 at 07:15 PM. Reason: PS
 
Old 08-23-2012, 12:22 AM   #53
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by FeyFre View Post
Not Opera, but SlackBuild for Opera. By definition packages built by SlackBuilds are intended to be used in Slackware and its heirs(sorry, derivatives), so doints.sh in those packages have 100% guarantee that it will be executed in Slackware environment.
You said it yourself, or derivatives, of which there are many and some of these are now quite different from Slackware. Additionally the SlackBuild is far from the only way to install Opera on Slack. It may well be that most of our Slackware users just use our cross-district install script rather than the SlackBuild. I have no way of knowing. Also how would the file ever get updated after an OS upgrade?

Anyway I'll stop now because we are into the world of make believe. I not going to have any package under my control make this file. Unless of course I one day decide to start my own distro! :-) Nah, I could never compete with the mighty Slackware. :-D
 
Old 08-23-2012, 12:49 AM   #54
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by FeyFre View Post
Basically I propose You to delegate task of gathering information about environment to distribution-specific installer( .t?z, .rpm, .deb). During installation data will be gathered and stored in Opera-specific path(for instance /usr/lib/opera/os-release). So when Opera crashes it knows that information about environment is stored in that hardcoded path).
Those packages are not distro specific. Any distro could potentially use our tar packages (since they have their own install script), there are hundreds of different distros that could use our debs and almost as many that could use the rpms. Also sometimes people do weird things like install an rpm directly on Slack (not a great idea but some people do it nonetheless). In theory a user could use any package (the binaries within them are identical). So knowing the package that Opera was installed from actually tells me very little about a user's distro.

P.S. As it happens Opera already tracks which package type it was installed from and this information is sent back to us when the program checks for updates. The information is in /usr/share/opera/package-id.ini. We do this as our plan is to introduce package specific upgrade instructions in the upgrade notification that appears when a new release comes out. We don't bother including this info in the crash logs and bug reports however since it is basically useless for that purpose.

Last edited by ruario; 08-23-2012 at 03:15 AM. Reason: nonsensical sentence; s,lib/opera,share/opera,
 
Old 08-23-2012, 07:47 AM   #55
bormant
Member
 
Registered: Jan 2008
Posts: 425

Rep: Reputation: 240Reputation: 240Reputation: 240
Quote:
Originally Posted by ruario View Post
How it would help me personally, is that it would allow Opera to include the distro name and version in our bug and crash reports.
So, why not to include /etc/*release /etc/*version?


Quote:
Originally Posted by ttk View Post
A file like this is often useful for determining what is "out there" in a datacenter environment.
Code:
% cat /etc/*version /etc/*release
already do this, doesn't it?

Last edited by bormant; 08-23-2012 at 07:48 AM.
 
1 members found this post helpful.
Old 08-23-2012, 07:57 AM   #56
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
@bormant: No it doesn't. The formatting of those files varies wildly (preventing automation of gather the version), additionally not every distro stores there file in that location using one of those naming formats. Off the top of my head, TinyCore only has it here: /usr/share/doc/tc/release.txt

Edit: Also, until the advent of /etc/os-release Arch Linux only had the file /etc/arch-release, which was a blank (zero byte) file. So your command would have printed nothing on Arch. Which again highlights the problem that there was no standard for the /etc/*version /etc/*release before /etc/os-release. Obviously the Arch devs felt it was enough that the file was there for people to check they were on Arch and figured a version number within the file made little sense on a rolling release distro but their implementation meant that the seemingly obvious "cat /etc/*version /etc/*release" would simply fail.

Last edited by ruario; 08-24-2012 at 12:12 AM. Reason: Added a second example
 
Old 08-23-2012, 08:33 AM   #57
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by bormant View Post
So, why not to include /etc/*release /etc/*version?
A further problem with this when writing a script to detect distros is the fact that many distros include multiple such files to show relationships to other distros that came before them, complicating how you decide which distro is actually running. Mageia for example has /etc/mageia-release, /etc/mandrake-release, /etc/mandrakelinux-release and /etc/mandriva-release. /etc/os-release handles this more gracefully with the ID_LIKE field. On Mageia they could write ID=mageia and have ID_LIKE="mandriva mandrakelinux mandrake".
 
Old 08-23-2012, 09:05 AM   #58
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
One way you can attempt to deal with multiple verison/release files when making script is to sort your testing for the precense of each potential version/release file by looking sequentially in reverse order to which the distro came into existence. For example you look for the /etc/mageia-release first. If found it is Mageia, if not, only then do you check then look for /etc/mandriva-release file.

This is another good highlight of the problem in trying to do this with any level of accuracy when /etc/os-release does not exist and why would will never automatically detect a new distro that doesn't have it. Your script needs a complete list of distros, when they came into existence, the name of the file they use and its internal format for listing version numbers.

Then you as a maintainer of that script need to keep a close eye on distrowatch for new upcoming distros that you might want to add to a future version of your script. You will also need to install each of them or search through their packages to try and find the distro version/release files. After updating your script you then need to find a way to roll this updated version out to all the places that use it. Basically, without a standard for defining your distro/distro version, like /etc/os-release provides, it is a minefield with lots of maintenance.
 
1 members found this post helpful.
Old 08-23-2012, 09:35 AM   #59
ttk
Senior Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 1,038
Blog Entries: 27

Rep: Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484
Quote:
Originally Posted by ruario View Post
One way you can attempt to deal with multiple verison/release files when making script is to sort your testing for the precense of each potential version/release file by looking sequentially in reverse order to which the distro came into existence. For example you look for the /etc/mageia-release first. If found it is Mageia, if not, only then do you check then look for /etc/mandriva-release file.
This is more or less what self-id does, though it checks for /usr/bin/lsb_release first:
Code:
sub detect_version {
  my ($hr) = @_;
  $hr->{'release'} = 'unknown';
  $hr->{'distro'} = 'unknown';
  $hr->{'version'} = '0';
  if (-e '/usr/bin/lsb_release') {
    foreach my $x (`/usr/bin/lsb_release -a 2>&1`) {
      chomp ($x);
      $hr->{'lsb'}     = lc($1) if ($x =~ /^LSB Version:\s+(.+)/);
      $hr->{'release'} = lc($1) if ($x =~ /^Description:\s+(.+)/);
      $hr->{'version'} = lc($1) if ($x =~ /^Release:\s+(.+)/);
      $hr->{'distro'}  = lc($1) if ($x =~ /^Distributor ID:\s+(.+)/);
      }
    }
  if ($hr->{'release'} eq 'unknown') {
    my $fh = undef;
    my $id_file = first_file("/etc/os-release", glob("/etc/*{-release,-version,_version}"), '/etc/lsb-release', '/etc/release'); # the ordering of these is important.
    if (defined($id_file) && open ($fh, "<", $id_file)) {
      if ($id_file eq "/etc/os-release") { # http://0pointer.de/blog/projects/os-release
        while (defined(my $buf = <$fh>)) {
          chomp($buf);
          $hr->{'release'} = lc($1) if ($buf =~ /^\s*pretty_name\s*=\s*"?(.*?)\"?\s*$/i );
          $hr->{'version'} = lc($1) if ($buf =~ /^\s*version_id\s*=\s*"?(.*)"?\s*$/i );
          $hr->{'distro'}  = lc($1) if ($buf =~ /^\s*name\s*=\s*"?(.*)"?\s*$/i );
          $hr->{'distro'}  = lc($1) if ($buf =~ /^\s*id\s*=\s*"?(.*)"?\s*$/i );
          }
        }
      elsif ($id_file eq '/etc/lsb-release') { # Ubuntu and Debian, though those likely have lsb_release installed.
        while (defined(my $buf = <$fh>)) {
          chomp($buf);
          $hr->{'release'} = lc($1) if ($buf =~ /^\s*Description\s*:\s*"?(.*?)\"?\s*$/i );
          $hr->{'version'} = lc($1) if ($buf =~ /^\s*Release\s*:\s*"?(.*?)\"?\s*$/i );
          $hr->{'distro'}  = lc($1) if ($buf =~ /^\s*Distributor[^\w]*ID\s*:\s*"?(.*?)\"?\s*$/i );
          }
        }
      elsif ($id_file eq '/etc/release') { # NetBSD, and maybe others?
        while (defined(my $buf = <$fh>)) {
          next unless ($buf =~ /^\s*([A-Z][^\s]+)\s+(\d[\w\.]+)/);
          $hr->{'release'} = lc("$1 $2");
          ($hr->{'os'}, $hr->{'version'}) = (lc($1), lc($2));
          $hr->{'distro'} = '';
          last;
          }
        }
      else {
        $hr->{'release'} = lc(<$fh>);
        chomp ($hr->{'release'});
        ($hr->{'distro'}, $hr->{'version'}) = ($1, $2) if ($hr->{'release'} =~ /(.+?)\s+release\s+([\d\.]+)/);
        ($hr->{'distro'}, $hr->{'version'}) = ($1, $2) if ($hr->{'distro'} eq 'unknown' && $hr->{'release'} =~ /^([\w]+)\s+([\d\.]+)/);
        }
      close ($fh);
      }
    }
  return;
  }
I wish "cat /etc/*version /etc/*release" were enough :-/ but as it is, even self-id is insufficient. For instance, it doesn't always handle the case ruario described of /etc/mageia-release first then etc/mandriva-release (the ordering returned by glob() is dependent on external factors). It's just been good enough to handle everything I've encountered so far. I'm going to fix it now to handle the mageia/mandriva case.
 
Old 08-23-2012, 09:48 AM   #60
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Original Poster
Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
@ttk: I suspect Mageia might be ok in any case as (Mageia 2 at least) have /etc/os-release.

Careful reading /etc/lsb_release. The format of this is not part of any LSB standard, only the "lsb_release" binary is, so you would be better calling that directly even though this introduces an extra overhead.

https://bugs.launchpad.net/ubuntu/+s...236/comments/2
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware 8.1 minimum install (including KDE) JaymzCobain Slackware 11 02-03-2004 07:09 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:02 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration