[Rear-users] Symlinks and maintainability

Jeroen Hoekx jeroen.hoekx at hamok.be
Tue Oct 12 13:27:12 CEST 2010


On 11 October 2010 21:42, Schlomo Schapiro <schlomo at schapiro.org> wrote:
> Hi,
> I managed to take a first look at your patch, sorry for the delay.

No problem, I was out-of-office last week :-)

> On 29/09/10 08:07, Jeroen Hoekx wrote:
>> Ideas attached to this message :-) It's more or less inspired by
>> mkinitcpio. We don't have it in our main branch yet, since we wanted
>> to know what you thought about it.
> Thanks a lot for submitting this suggestion, it is an interesting way of
> generalization.

Well, we only needed the generalization because we had "problems" with
symlinks and wanted to reduce their count.

- our SVN checkout didn't work on RHEL 5 because of a missing symlink
- Dag's initial checkout was done using the tar for a specific
revision, created by the SF subversion. It converted all symlinks into
the files they pointed to and we had some initial problems because of
the confusion that had created :-)
- since the initial solution as discussed on this list preferred
OUTPUT=OBDR, we had to symlink all the ISO code into that directory, I
didn't catch all of them the first times I tried.

So we've been thinking about reducing the amount of symlinks, while
still staying in line with the ReaR philosophy.

> Some thoughts for discussion (and I really would like to hear some more opinions
> about this topic):
> * for running pre_rceovery/post_recovery stuff I reall prefer to use certain
> number ranges for this job as I believe that it will do it without changing the
> ReaR structure

We don't want to run code pre_recovery as such, we need code in
various stages (verify, restore...), but only under certain
circumstances (NETFS_URL=obdr://*) . To do this, we had to add some
code which allowed easy pre/post recovery code acces for the reasons
given below and so the "hooks" got in.

> * AFAIKT you want to have some kind of a computational configuration stage which
> comes after the human-input configuration and is able to compute some further
> configuration and maybe even change the running structure. The ReaR design
> basically has the prep stage for this purpose and assumes that during recovery
> there is nothing to "find out" because it has been all decided during the dr &
> rescue stages. If you need to remember something for the recovery you should
> create a recovery.conf file which is read in addition to all the regular conf
> files. This would be similar to how we create an os.conf file to skip taking
> lsb_release into the rescue system.
> * I understand your generalization concept and would like to draw your attention
> to the following points:
>  * The words you chose (target and environment) where not self-explanatory to
> me (though I can't see something better ATM), I had to read through all the
> patched code to get the whole idea.

Agreed, it was also one of Dag's reactions, but I couldn't find a
better name either... I think environment is quite good. It's "target"
that sounds wrong.

>  * As ReaR is now it is already not so easy to grasp for the new user. With the
> total generalization I am afraid that it will be even less comprehensible except
> to those who are ready to dive deep into the code.

My approach when we started off with ReaR was to just run in
simulation mode, see which files were included and modify them. I did
not know how it worked exactly back then, but was still able to
complete a working version of the OBDR code in a relatively small

To make sure simulation mode always shows the correct files, is why I
have to do things before the prep stage.

> * I am still not convinced that it is not equally possible to solve all your
> problems by subtly changing the location or the cutting of existing scripts.

We can merge the OBDR code into the ISO code. But I think it's better
to keep it separate. We can't test on all possible architectures or
OS's. This patch would allow additions without such possible
far-reaching issues. That's why we wanted to ask first :-)

> Maybe you can show me your current branch and tell me what you percieve as pain
> there and I can try to find a solution? IT happened before that the addition of
> new feature code came along with a major shift in the other scripts and IMHO the
> inner layout of the scripts is not a stable interface to the outside.

We need customer agreement to publish the code (this particular patch
was not developed at the customer).

> So, please more opinions and please let us find a solution to your problems with
> the current layout before changing it (= give me a fair chance to try). If that
> fails you can consider the idea as accepted by me, but I really would like to
> hear more opinions (yes, I repeat myself: relevance = redundancy :-) ).
> Some questions about the patch:
> TARGETS="$TARGETS $environment/*.sh"
> * why not use arrays here and rely on the bash completion to do the right thing?

I tried to use arrays, but gave up when I couldn't get it expanding
after two tries :-)

> * that way it would be also possible to check for empty $TARGETS
> * I have to admit that I don't remember now why I used ls -d instead of echo
> here, maybe related to empty stages or something like this. Could probably be
> solved much better than my old code.
> if [ "$BACKUP" == "NETFS" ] && [ -n "$NETFS_URL" ]
> * what is bad about [ cond -a cond ] style ?

No short-circuit (according to ABS) ?

> * according to "help test" = would be appropriate, somehow == is there for some
> compatibility with something else

It's a synonym in bash, and I typed it out of habit. I will adapt it
to the upcoming guidelines.

> * Yes, I am picky but IIRC there was a bash coding style discussion recently on
> this list :-)
> usr/share/rear/hooks/post_config/netfs.sh
> * I guess I really would like to see some info in the log that the running
> layout had been changed. Otherwise it is so much guesswork while debugging

Simulation mode shows which "targets" are run, but I will add some logging.



> Again, interesting approach worth discussion,
> Kind Regards,
> Schlomo
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Rear-users mailing list
> Rear-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rear-users

More information about the rear-users mailing list