[Rear-users] Symlinks and maintainability

Schlomo Schapiro schlomo at schapiro.org
Mon Oct 11 21:42:11 CEST 2010


Hi,

I managed to take a first look at your patch, sorry for the delay.

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.

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

* 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.
  * 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.

* 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.
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.

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?
* 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 ?
* according to "help test" = would be appropriate, somehow == is there for some
compatibility with something else
* 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

Again, interesting approach worth discussion,
Kind Regards,
Schlomo




More information about the rear-users mailing list