Quote:
In addition, I actually think it would be a horrible idea if Opera created files that have nothing to do with Opera. |
Quote:
Eric |
Quote:
Quote:
Quote:
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). |
Quote:
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 ? |
Quote:
For sure your reply makes it very clear that I will not touch any of your packages unless after triple-checking. Eric |
Quote:
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. |
Quote:
PS: Forced to quit this discussion due language barrier. |
Quote:
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 |
Quote:
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. |
Quote:
Quote:
Code:
% cat /etc/*version /etc/*release |
@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. |
Quote:
|
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. |
Quote:
Code:
sub detect_version { |
@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 |
All times are GMT -5. The time now is 09:22 AM. |