Add support for AIX (closes #241)#311
Conversation
|
Can we have a quick thought from you on this @sethmlarson if you don't mind ? 🙇 |
There was a problem hiding this comment.
I'd like to raise concerns that AIX is (Unix but) not Linux and that hence putting AIX bits into class LinuxDistribution seems like mis-leading modelling. Also I see a mix of host and target system here, e.g. host sys.platform is inspected no matter if .root_dir is /or not, same for the call to oslevel. Just my two cents
ad1d0b0 to
8f8cae3
Compare
You're right, this seems related to the same questions raised in #177 about this module architecture. At the moment, despite renaming
You were absolutely right, please take a look to the updated (and rebased) patch, it aims at improving host and target system information separation (surprisingly it simplified testing and I think this would improve detection rate OOTB). Bye, thanks for your time Sebastian 🙇 |
hartwork
left a comment
There was a problem hiding this comment.
@HorlogeSkynet I see some good ideas here, but I'm unsure if this approach will work without use of a chroot-like approach, which I don't see here: adjusting PATH alone will not keep the commands we are calling from reading files outside/upwards .root_dir. Am I missing something?
No you don't, I actually did think about that before adapting this patch, but then forgot 🤔 Note : how could we then support EDIT : I think I got an idea to keep this "BC" for Windows, stay put 😌 |
|
So I'm back Sebastian, latest thoughts on this topic :
As AIX detection would be based on information gathered from Where do you think we should go from here ?
Bye 👋 |
The global idea here is about preferring no data instead of misleading ones if `-r` is set (for instance, by calling a binary returning host information). This patch additionally introduces a new `include_third_bins` parameter, controlling third-party binaries execution (as AIX' oslevel command). See #311 for complete thread.
8f8cae3 to
bf3106a
Compare
|
Dear Sebastian @hartwork, dear maintainers, You will find here an updated branch, with 4 (rebased) commits :
Rationale about A new parameter has been introduced ( To conclude, a very quick GitHub search shows(?) that actually no one uses this parameter from API (at least on this forge). Bye, thanks for your time ! 👋 |
hartwork
left a comment
There was a problem hiding this comment.
Hi @HorlogeSkynet , good summary, sorry for not getting to a review and reply earlier:
The global idea here is about preferring no data instead of misleading ones if `-r` is set (for instance, by calling a binary returning host information). This patch additionally introduces a new `include_oslevel` parameter, controlling the execution of (AIX) oslevel command. See #311 for complete thread.
https://build.opensuse.org/request/show/955104 by user sebix + dimstar_suse - remove shebang from distro.py - update to version 1.7.0: - BACKWARD COMPATIBILITY: - Dropped support for EOL Pythons 2.7, 3.4 and 3.5 [[#281](python-distro/distro#281)] - Dropped support for LSB and `uname` back-ends when `--root-dir` is specified [[#311](python-distro/distro#311)] - Moved `distro.py` to `src/distro/distro.py` [[#315](python-distro/distro#315)] - ENHANCEMENTS: - Documented that `distro.version()` can return an empty string on rolling releases [[#312](python-distro/distro#312)] - Documented support for Python 3.10 [[#316](python-distro/distro#316)] - Added official support for Rocky Linux distribution [[#318](https://github.com/python-distro/distr
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host own materials.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files.
This patch is a followup of #311. It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files. Note : this patch **only** changes `root_dir` behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files. Note : this patch **only** changes `root_dir` behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files. Note : this patch **only** changes `root_dir` behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that a symbolic link present under `root_dir` could be blindly followed _outside_ of `root_dir`, possibly leading to host files. Note : this patch **only** changes `root_dir` behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that symbolic links present under `root_dir` could be blindly followed, eventually leading _outside_ of `root_dir` (i.e host own files). Note : this patch **only** changes LinuxDistribution's `root_dir` parameter behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that symbolic links present under `root_dir` could be blindly followed, eventually leading _outside_ of `root_dir` (i.e host own files). Note : this patch **only** changes LinuxDistribution's `root_dir` parameter behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that symbolic links present under `root_dir` could be blindly followed, eventually leading _outside_ of `root_dir` (i.e host own files). Note : this patch **only** changes LinuxDistribution's `root_dir` parameter behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that symbolic links present under `root_dir` could be blindly followed, eventually leading _outside_ of `root_dir` (i.e host own files). Note : this patch **only** changes LinuxDistribution's `root_dir` parameter behavior.
This patch is a followup of #311 (2a89f76). It appeared that we were not resolving paths when reading from files. This means that symbolic links present under `root_dir` could be blindly followed, eventually leading _outside_ of `root_dir` (i.e host own files). Note : this patch **only** changes LinuxDistribution `root_dir` parameter behavior.
No description provided.