run symlink dynamically during mkrescue¶

Labels: enhancement, fixed / solved / done

pcahyna opened issue at 2025-01-13 18:38:¶

Pull Request Details:¶

Type: Enhancement
Impact: Normal
Reference to related issue (URL): Fixes #3375
How was this pull request tested?
rear -d mkrescue before and after the change and check that rootfs (/var/tmp/rear..../rootfs) has only trivial changes and that /var/tmp/rear..../rootfs/var/ contains the run -> ../run symlink.
Description of the changes in this pull request:
Introduce a script that can create symlinks and empty directories in the rescue ramdisk if they exist in original system. This way one can avoid having plenty of empty directories under usr/share/rear/skel. For now, use it to create the /var/run symlink. Not having it as an actual symlink in the source tree helps avoiding pitfalls associated with symlinks in the source tree, in particular the packaging problem that RPM is not able to change a directory into a symlink and vice-versa during upgrade (before ReaR 2.8 it was a directory, not a symlink): https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ and issue #3375.

jsmeix commented at 2025-01-14 07:16:¶

I created a new milestone "ReaR 2.8.1"
and assigned this pull request to it
if we like to release ReaR 2.8.1

jsmeix commented at 2025-01-14 07:28:¶

I just merged
https://github.com/rear/rear/pull/3373
as
https://github.com/rear/rear/commit/78954fb6d630e5dfe33870ae6cbb5170eb4f39ff
see
https://github.com/rear/rear/pull/3370

pcahyna commented at 2025-01-14 10:57:¶

Hi @jsmeix , thanks. I will rebase my branch. The problem with the codespell check is that it is triggered even by what it sees as an error in the old version, untouched by the commit. So if you ignore the error once, because it is a false alarm, you will get it again and again. Which is the situation that we wanted to avoid with Differential ShellCheck.

pcahyna commented at 2025-01-14 11:00:¶

Note also that the title of the check in https://github.com/rear/rear/pull/3380/checks is "🔸 Check for Spelling Errors for Changed Files", but this is misleading, as it then complains about an error in an unchanged file.

https://github.com/rear/rear/actions/runs/12753838460/job/35546345794

pcahyna commented at 2025-01-14 11:07:¶

Which is weird, as there is this argument: --exclude-file ./exclude_file and ./exclude_file contains ./doc/rear-release-notes.txt as shown in the output of the previous action.

jsmeix commented at 2025-01-14 11:18:¶

In https://github.com/rear/rear/pull/3380/checks
I see

/usr/bin/docker ... --rm -e "EXCLUDE_FILE"

so it looks as if the exclude file gets removed?
But I know nothing at all about how that stuff actually works.

pcahyna commented at 2025-01-14 11:32:¶

No,

       --rm true|false
          Automatically  remove  the  container  when it exits. The default is
       false.

The question though is whether the file gets passed into the container, and if yes, whether it is at the path where the command expects it (IOW whether the working directory of the command is the directory where the file resides).

pcahyna commented at 2025-01-14 15:39:¶

Rebased to solve the codespell fail. The original failed run is preserved at https://github.com/rear/rear/actions/runs/12753838460/job/35546345794

schlomo commented at 2025-01-14 16:43:¶

@jsmeix in the maintainer talk we talked about not doing a "patch release" 2.8.1 but just a regular next release 2.9. See the notes for more context. WDYT?

jsmeix commented at 2025-01-15 07:01:¶

I edited the milestone "ReaR 2.8.1" title to "ReaR 2.9".
Personally I don't care much about version numbers
(except that they must be strictly monotonic increasing).

gdha commented at 2025-01-16 09:21:¶

Rebased to solve the codespell fail. The original failed run is preserved at https://github.com/rear/rear/actions/runs/12753838460/job/35546345794

Seems to me there is still a bug in codespell itself - see https://github.com/codespell-project/actions-codespell/issues/33#issuecomment-903241775

gdha commented at 2025-01-21 07:43:¶

@pcahyna Do you still have some doubts to merge this PR? How can we help?

pcahyna commented at 2025-01-21 19:12:¶

Alternatively, maybe tar --no-recursion ... | tar ... might be another simpler way to copy directories and symlinks alike and even also copy over the permissions in one go.

Done.

pcahyna commented at 2025-01-21 19:13:¶

@pcahyna Do you still have some doubts to merge this PR? How can we help?

No, I only wanted to implement @schlomo 's proposal and took me some time to return to it.

pcahyna commented at 2025-01-23 14:28:¶

@schlomo @jsmeix I believe I addressed all your comments and I would like to rebase and merge today.

pcahyna commented at 2025-01-24 13:11:¶

I am now going to do a 2.9 release using the steps from #3370 and #3238 (minus the creation of a release branch).

schlomo commented at 2025-01-24 13:16:¶

Thank you very much @pcahyna, much appreciated!

jsmeix commented at 2025-01-24 13:23:¶

@pcahyna
I dare to ask you for a big favour:
Could you while you are doing it review our
https://github.com/rear/rear/wiki/Release-process
and (preferably even pedantically) verify
to what extent those instructions are accurate?

I modified it a lot during my ReaR 2.8 release
but I was somewhat under stress at that time
so my current version is likely not yet OK.

jsmeix commented at 2025-01-24 13:25:¶

@pcahyna
and try to keep relaxed with release notes creation ;-)

pcahyna commented at 2025-01-27 16:50:¶

@pcahyna I dare to ask you for a big favour: Could you while you are doing it review our https://github.com/rear/rear/wiki/Release-process and (preferably even pedantically) verify to what extent those instructions are accurate?

I modified it a lot during my ReaR 2.8 release but I was somewhat under stress at that time so my current version is likely not yet OK.

@jsmeix sure! So far I will only skip the release branch creation.

pcahyna commented at 2025-02-03 21:27:¶