-
-
Notifications
You must be signed in to change notification settings - Fork 254
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
Begin Standardization and Rewrite #938
Conversation
d53a15e
to
71aaacb
Compare
5ad791d
to
2abab28
Compare
3e7ea17
to
2264391
Compare
847d516
to
d1173dd
Compare
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 have done a quick review of all files, overall looks good, thanks for this huge effort!
I did not look closely into the following parts:
- Dockerfiles (you know better)
- nodejs (not familiar with)
- packages.bash (too many substantial changes to give a valid statement)
My recommendation would be to play around with all the installers in using packages.bash ... and if this is all fine for you, merge.
A few comments from my side, please check if you want to consider them.
functions/helpers.bash
Outdated
|
||
local repoKey | ||
|
||
repoKey="$(mktemp "${TEMP:-/tmp}"/openhabian.XXXXX)" |
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.
never heard of $TEMP on Linux, just googled it
https://unix.stackexchange.com/questions/352107/generic-way-to-get-temp-path
propose to roll back to old command if there is no strong reason behind
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.
Well we should have a variable a user can set.
Let's use $TMPDIR then.
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.
Why that? /tmp
is POSIX standard.... I prefer to keep it simple...
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.
Its so that the user has the option to change the tmp dir as there were some complaints about it not being big enough in the community.
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.
To be honest, I disagree. This is not the Linux way of dealing with that. Then tmp is too small anyway and needs to be mounted somewhere else.
My recommendation: Keep is simple and predictable. Don't do it.
@mstormi ?
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.
Why that?
/tmp
is POSIX standard.... I prefer to keep it simple...
I believe you misunderstood. By default, /tmp
IS used if $TMPDIR is unset, see code.
But for cases where it is too small - I myself have hit that on Java upgrade - the user must be able to override it, hence $TMPDIR.
This is not the Linux way of dealing with that.
Well, as a longterm admin I disagree. I've been using $TEMP 20 yrs ago already before Linux.
But this is not about Linux, let's shortcut dogma discussions .... as an openHABian maintainer trying to build a tool that saves users from a need to descend into UN*X hell, I see this to be a must. If there's whining about /tmp full, we can tell the user to set $TMPDIR to e.g. /var/tmp or some self-mounted temp dir.
@@ -177,6 +184,12 @@ is_raspbian() { | |||
[[ "$(cat /etc/*release*)" =~ "Raspbian" ]] | |||
return $? | |||
} | |||
# TODO: Not official yet, update when os-release file actually reflects the name change | |||
is_raspios() { |
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.
As you mentioned above, this won't work yet.
A few days ago the 32 bit version still returned "Raspbian", the 64 bit returned "Debian"...
Anyhow, where should we try to distinguish? For now, a Raspbian has to be handled same as a Raspberry Pi OS. So why do we need an additional function?
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.
Markus wanted it added to have the template there for when it is officially changed.
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.
But it does neither work at the moment not does it have a good use case, so still my recommendation to remove it.
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'll take the pragmatic approach and leave it in (else this merge would take another day or two).
But we all know it's not correct yet, not used yet and needs to be revisited once we plan on making use of it.
In all of my testing the functions I have changed have functioned properly. I am ready if you guys are. |
7135167
to
eaf4e46
Compare
Also this includes further changes in terms of the Standarization and Rewrite. Fixes openhab#949 Related openhab#519 openhab#625 Signed-off-by: Ethan Dye <[email protected]>
thanks for your work! |
@ecdye please check the Adopt repo, many tests to fail, e.g. |
I know, I am looking at it right now, I think that they updated some of the packages this morning and then screwed something up because up until now all tests have passed. I am working on figuring out if it is on our end that something needs to change or theirs. I'll post when I have updates. |
adoptium/infrastructure#1399 It's jfrog we are fine we just have to wait it out. |
The issue appears to have been fixed. |
There was a minor error in the code for Node-RED installation following openhab#938. This corrects that error. Signed-off-by: Ethan Dye <[email protected]>
There was a minor error in the code for Node-RED installation following #938. This corrects that error. Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in openhab#938. Related openhab#937 Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in openhab#938. Related openhab#937 Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in openhab#938. Related openhab#937 Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in openhab#938. Related openhab#937 Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in openhab#938. Related openhab#937 Signed-off-by: Ethan Dye <[email protected]>
This contains further rewrites that improve the consistency of the codebase. These were made in addition to the changes that were first started in #938. Related #937 Signed-off-by: Ethan Dye <[email protected]>
Begins a rewrite of the openHABian core code to make it overall safer
and more verbose in failure. Additionally this helps to standardize the
coding format.
This contains major a major rewrite of 'packages.bash',
'nodejs-apps.bash', and other minor fixes in other files as well. This
also contains the proper testing functions using BATS for the rewritten
code.
Fixes #936
Related #937 #949
Fixes #856
Fixes #633
Signed-off-by: Ethan Dye [email protected]