[VOTE] Re: directory-handling with nALFS
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Sat Apr 3 06:23:19 PST 2004
> I'm sorry, that you think that way.
> I thought, it's not an error if something already exists, what I like to
Please understand that I'm not disagreeing with this point, but we have
to find a way to achieve this that works with _all_ ALFS
implementations, not just nALFS. There are not currently any nALFS
options (specified in nALFSrc) that change the execution behavior of the
handlers, and I want it to stay that way. Every piece of information
needed for the handler to know how to perform its tasks should be in the
profile. Think of this way: Vassili's YAALFS is a fully conformant ALFS
implementation (that creates bash scripts), so if you fed it one of
these profiles how would you expect it handle a pre-existing directory,
without additional information in the profile to tell it do that?
Also, <mkdir> accepts a "permissions" parameter, to specify what the
desired permissions on the directory should be. What should happen if
the directory already exists but the permissions are different? (This
would happen if the profile has already been run, but then changed to
specify different permissions).
> If I have to change nALFS just for my needs, then I see no benefit using it.
> Then I could reach the same using Makefiles and don't have to patch something
> "just for me".
I would disagree that there is "no benefit using it", as any Makefile
system is not going have to a user interface, provide logging into
usable XML log files, be executable on a remote system (in a future
release of nALFS), etc.
> Of cause! I'm quite sure, that you have a lot to do.
> I didn't expect you doing it.
> I just want to know, if I work it out and send you the patch - are you willing
> to apply it? - no more.
If you can come up with a DTD 3.2 syntax change that provides the
behavior you are looking for, a way to implement it that doesn't break
if the user specifies a shell-specific path for the <mkdir> element and
a way to document it so that users can understand how it works and what
its limitations are, then yes I'll very likely apply it.
However, you've got a big hurdle to get over: The example I provided
before (repeated below) works just fine with DTD 3.2 (and there is a
alternate version for 3.1), is easy for your book->profile tool to
produce, and works with all conforming ALFS implementations.
> P.S. I found a little tipo in syntax_doc
> Element <move>
> is: ... sub-element option is an option of the mkdir command.
> should be: ... sub-element option is an option of the mv command.
Please enter a Bugzilla entry for this, James will take care of it. Thanks!
More information about the alfs-discuss