RFC: variables to check for OS, distribution, etc. #3058
Comments
|
Some detail on the usage: these variables could be built-in, and resolved lazily by opam, which means they would be accessible anywhere in |
|
to extend your above table, let me show you the output on some FreeBSD systems:
I'd propose to use |
|
@hannesm ok, so that would mean the following changes:
EDIT: and thanks a lot for the input :) |
|
@AltGr I'd suggest to use |
|
That looks pretty good to me! I am not an expert in the wild jungle of distribution, but that proposal seems to improve the current state of |
|
So, I have a prototype implementation for this in this gist. Try it out with the following command and report results ! Please test on any exotic systems you might want to check depexts on, and tell wether the results would be accurate/convenient enough for you. Some detailsThe prototype has some changes compared to the above:
ExamplesMy preliminary examples: |
|
|
Thanks for the confirmation that it works on android, I had trouble getting OCaml to work on my phone :) |
This system is nowadays known under the name |
|
Here are values from my laptop and and a rpi2 running raspbian. |
I think the way you handle version across systems under |
|
Ok, thanks for the input. I'll rename |
|
Some more changes:
|
|
I think it would be useful to get @dra27's input w.r.t windows identification. Currently we will have according to In the Also @dra27 what are your toughts w.r.t. to depexts on windows ? Can Btw. @AltGr on my side I have used |
This closes ocaml#2919 This replaces the current obscure and verbose depexts format by lists of system package names and filters based on opam variables, e.g. : depexts: [ ["libssl-dev"] { os-distribution = "debian" | os-distribution = "ubuntu" } ["openssl-devel"] { os-distribution = "centos" & os-version >= "7.2" } ] The old format still parses, and is rewritten by the package migration function (older packages in 2.0 format won't be rewritten and may get broken depexts, as we don't want to retain compatibility with beta format versions) All tags currently present in `opam-repository` are supported, except for `source`, which is discarded (they were in the same namespace and now need to be classified between `arch`, `os`, etc.) Note that the rewrite needs to know about the variables defined and their values. This is based on ocaml#3058 and https://gist.github.com/AltGr/5bfc8cea6f01e74b95de79ceaba39369, version 4, but may still change. Opam itself does not define these variables at the moment (except for `arch` and `os`, but not with the same normalisation yet), and the command-line format changes too, which means that current `opam-depext` will be broken by the changes. The new format is opam list --external --vars arch=x86_64,os=linux,os-distribution=debian instead of opam list --external=x86_64,linux,debian which was more ambiguous and less generic, if shorter. The idea is that the variables will later be built in opam, so the user won't need to declare them for normal usage.
This is not backwards compatible. The system analysis and generation of the variable is done according to ocaml/opam#3058 (https://gist.github.com/AltGr/5bfc8cea6f01e74b95de79ceaba39369), but is intended to be moved to opam at some point. When that happens, this tool will be limited to handling the various package managers, deciding from the opam variables using e.g. `opam var os-distribution`. Note that this drops support for "source" tags, which aren't supported by beta5 anymore.
|
For FreeBSD systems above: the other systems don't have any OCaml installed. The |
|
@hannesm thanks. Indeed I replaced them by |
This is not backwards compatible. The system analysis and generation of the variable is done according to ocaml/opam#3058 (https://gist.github.com/AltGr/5bfc8cea6f01e74b95de79ceaba39369), but is intended to be moved to opam at some point. When that happens, this tool will be limited to handling the various package managers, deciding from the opam variables using e.g. `opam var os-distribution`. Note that this drops support for "source" tags, which aren't supported by beta5 anymore.
|
Ubuntu LTS 16.04.3 on a 64bits machine: |
Following #3058, this brings the system detection code in
Here is a proposal for new pre-defined variables, with examples. It's mostly inspired from the current state of opam-depext.
First some examples:
archis the output ofuname -m, withi?86rewritten tox86,amd64rewritten tox86_64. We might want some normalisation onarmtoo ? Note: any solution for Windows ? Assumex86_64?osis either the output ofSys.os_type, or the lowercased output ofuname -swhen the former isUnix, except forbsdin the case of*BSDandDragonFly(this differs fromdepext). Note: should the win32/cygwin distinction rather be made at thedistributionlevel ? Do we want to translatedarwintoosx?distributionis (originally following code from opam-depext):homebrewormacportthat has a binary installed (resp.brewandport) , or undefined otherwiseID, from/etc/os-release, or/usr/lib/os-release, or the output oflsb_release -i -sif that exists, or the first word of any of/etc/{redhat,centos,gentoo}-releaseor/etc/issue. The result is always lowercased. We could also definedistribution-familyusing the (first word of the) fieldID_LIKEfromos-release, falling back todistributionif that is not defined (useful to get the package manager, for example).uname -swhenosisbsd, yieldingfreebsd,openbsd,dragonfly...androidifgetprop ro.build.version.releaseexists and returns 0dist-versionisos-releasefieldVERSION_ID(see above), or some custom parsing of the different other cases that needs to be investigatedsw_vers -productVersion(note: this is the OS version and not the distribution version — versions of macports/homebrew don't really make sense here. Maybe find a better name for this variable ?)ver? There are solution using greps on the output ofsysteminfo, but that's extremely slow.getprop ro.build.version.releaseuname -r(this is in general the kernel version, but it seems to match OS releases on *BSD ? Is it correct ?)The fact that it is a big zoo was my main reason to do this as a plugin first, so that it could evolve and be fixed more rapidly than opam :)
Note: I am not sure
distributionis the best term in general, as that seems Linux-specific; but had no idea for a better name.dist-versionisn't a perfectly accurate name, either. Also, a OSX user may have both homebrew and macports, so in that case we assume they want to use homebrew...Should we add
os-version, which would make more sense on non-Linux OSes, and point to the kernel version on Linux ? Or just renamedist-versiontoos-version, since we don't care about the kernel version ?Please if you have access to / need support for any specific system, check the above, extend, propose, and give feedback! Thanks.
The text was updated successfully, but these errors were encountered: