-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for AIX (closes #241) #311
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Can we have a quick thought from you on this @sethmlarson if you don't mind ? 🙇 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🙇 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 ! 👋 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
The global idea here is about preferring no data instead of misleading ones if `root_dir` parameter is set (as this may result in calling a binary returning host information). If developers used to set `root_dir` and purposely included LSB, uname or oslevel commands, a warning will now be emitted. See #311 for complete thread and rationale.
928cecd
to
bd750b6
Compare
The global idea here is about preferring no data instead of false ones if `root_dir` parameter is set (as this may result in calling a binary returning, for instance, host information). Developers used to set `root_dir` and purposely including LSB, uname or oslevel commands will now get a `ValueError` exception during class initialization. See #311 for complete thread and rationale.
bd750b6
to
bee21c1
Compare
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.
No description provided.