[VOTE] Re: directory-handling with nALFS

Kevin P. Fleming kpfleming at linuxfromscratch.org
Sat Apr 3 06:23:19 PST 2004

Reinhard wrote:

> I'm sorry, that you think that way.
> I thought, it's not an error if something already exists, what I like to 
> create.

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.

   <test>-d .../path/to/directory</test>

> P.S. I found a little tipo in syntax_doc
> Element <move>
> 	Description
> 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 mailing list