Bruce Dubbs wrote: > Yes. Is there something wrong with that? Changing the book is the wrong approach. Especially, changing the commands in the book is the wrong approach. There are changes in the format of the underlying XML to accomodate scripting (and therefore jhalfs) but I personally feel that's different. That isn't actually altering anything in the method.
The commands are there not for the sake of automation, but to provide a technically correct methodology into building your own system. What would be the explanatory text for such a command? Somethin like: "We're installing this node here for the sole purpose that things are comfy for you when you want to re-enter chroot. If you forget to delete it, it'll probably be there in your system forever, but don't worry it only takes up a couple of bytes." Sure it's harmless, but it just doesn't fit with idea of providing technically accurate commands. If you want to change the way jhalfs works so that it can make the scripting of the book easier, propose a change to the way jhalfs operates. >> I'm not intending to be unsympathetic. I just don't understand how your >> proposed command really benefits the average end user. > > In a lot of cases, it won't. But what does it hurt? We do a lot of things > that > are not, strictly speaking, minimal. I don't believe it's about simply minimalism, but it's about keeping to the point. If it is really beneficial to many users in various circumstances to have such a command in the book, great, add it. But if it's just because you want to make the jhalfs experience nicer, it feels a good deal more appropriate to modify jhalfs. In any case, it's such a small and harmless command that it really doesn't matter except in principle. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
