Skip to content
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

tests: fail when we cannot mv original os-release #373

Merged
merged 3 commits into from
Jan 25, 2024

Conversation

evelikov
Copy link
Collaborator

@evelikov evelikov commented Dec 6, 2023

If we cannot move the os-release file(s) then the test should error out - fix that.

While here adjust the trap location, so it does not trigger on cp failure or when there's no file to copy in the first place.

Minor fixup of #351

@hyperupcall can you give this a quick look? I should have drank more coffee before reviewing 😅

Copy link
Contributor

@hyperupcall hyperupcall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix - I just had one comment :)

trap osrelease_cleanup EXIT

mv_osrelease() {
if [ -f "$1" ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if [ -f "$1" ]; then
if [ -f "$1" ] || [ -L "$1" ]; then

Should we keep previous behavior of moving a broken symbolic link?

Copy link
Collaborator Author

@evelikov evelikov Dec 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point - forgot that many distros have /etc/os-release as symlink.

The man page says "if it exists" where dkms code uses "-r". I'm inclined to change this + dkms code to "-e" which will stick to the man page + from brief test, it will skip if a broken symlink.

Maybe even throw in a test - both present but cannot be read, just for the fun of it.

What do you think?

Copy link
Contributor

@hyperupcall hyperupcall Dec 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that sounds good - I like the idea of using -e. From my testing as well, it seems there is no difference compared to -r when dealing with broken symbolic links:

$ ls
$ ln -s a b
'b' -> 'a'
$ cat b
cat: b: No such file or directory
$ cat a
cat: a: No such file or directory
$ [ -e b ] && echo 'yes'
$ [ -r b ] && echo 'yes'
$ [ -f b ] && echo 'yes'

so the change should be compatible

evelikov and others added 3 commits January 9, 2024 10:58
The man page says "if it exists", so let's do that. In practical sense
there should be no difference in behaviour since all Linux distros that
I've seen use 0644 permissions for the file.

Signed-off-by: Emil Velikov <[email protected]>
If we cannot move the os-release file(s) then the test should error out
- fix that.

While here adjust the trap location, so it does not trigger on cp
failure or when there's no file to copy in the first place.

v2:
 - check with -e, as per `man os-release`

Signed-off-by: Emil Velikov <[email protected]>
... otherwise we may alter the permissions and/or dereference the
symlink.

Signed-off-by: Emil Velikov <[email protected]>
@evelikov
Copy link
Collaborator Author

evelikov commented Jan 9, 2024

Added a prep commit updating dkms to use -e. Also added a follow-up commit to use cp --archive otherwise the file permissions and/or symlink status is not preserved.

@evelikov
Copy link
Collaborator Author

The Gentoo CI is failing, which is pre-existing and unrelated to this PR. Merging

@evelikov evelikov merged commit 6c12b22 into dell:master Jan 25, 2024
5 of 23 checks passed
@evelikov evelikov deleted the move-trap branch January 25, 2024 16:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants