[Rear-users] Symlinks and maintainability
jeroen.hoekx at hamok.be
Tue Sep 28 14:15:23 CEST 2010
In our project, we are currently using:
To implement this, we had to add symlinks to all files of the
OUTPUT=ISO target in the $stage/OBDR/ directory structure. In our
opinion this will quickly become unmaintainable. When the ISO creation
code gains new functionality, care must be taken that it is added to
OBDR mode and that there aren't any conflicts. We have also had many
problems when forgetting to add symlinks in other parts of the code
and upstream ReaR was also not symlink trouble free :-) Another
downside is that they don't get along with subversion very well.
We would like to discuss what you think about these issues and how we
can go forward. In its simplest form, it comes down to this: we want
to include both the ISO and OBDR code when running rear without having
to maintain symlinks from OBDR/ to ISO/*.
One solution we have thought of would lead to a configuration of:
Extra code would be imported by observing the URI scheme of NETFS_URL.
Currently, the directories where scripts are loaded from are
hardcoded. This should be made dynamic.
Another issue is that the code to decide which directories to scan
needs to run after the configuration is known, but before the first
stage is sourced. There are already ad-hoc provisions in the ReaR code
to run code before and after the recovery phase. Maybe it's good to
generalize this idea to other moments, so code could run at
"post_config" (which we need), "pre_recovery" or "post_recovery"
(which is implemented already).
I think such an "event" or "hook" mechanism fits in well with ReaR's
modular approach. It avoids maintenance of 20-something symlinks for
only a few additional lines of code. Your views?
More information about the rear-users