Preparing for nALFS 1.3 release
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Sat Feb 7 16:00:58 PST 2004
Jamie Bennett wrote:
> On Sat, 2004-02-07 at 17:42, Kevin P. Fleming wrote:
>>#641 - adding a config file option to specify the shell to be used for
> Not overly concerned on this one, does anyone actually want this?
It was on Neven's wish list when the Bugzilla conversion happened, and
it's easy to do so I'll take care of this evening.
>>#696 - template handler
> needed but handlers vary wildly and a generic handler may be hard to
True, and personally I would just look at existing ones to use as a
template for a new one, so I think I'm going to close this BZ entry as
>>#645 - <shell> element inside <execute>, to support script blobs in a
> Could be useful but again I wouldn't consider it a stumbling point on
> the way to 1.3.
I only listed this one because I personally have use for it :-)
> Ok, my thoughts on the current bugzilla,
> I'd like to see bug #604 (LSB stuff) either removed or have its priority
I have just looked over the LSB's CVS repository, and I don't see many
changes there at all. The only significant ones revolve around the
<cond> element, for which we now have a much better implementation with
the new <if> element. Their <cond> element supports a "switch" like
syntax for testing the architecture of the system nALFS was compiled on
(not what it is running on or building for), which could be emulated
with multiple <if> elements quite well. If someone out there _really_
wants to have this switch-type logic available, then we'd need to
discuss just adding <switch> and <case> elements to do it the right way.
If noone in the current user base really cares about this one, I think
it can just be resolved as "no longer relevant".
> #609 seems a small but nice change to have completed. I haven't looked
> in to it so there may be more to it. Also applies to #638 and #642
Agreed, although I haven't looked at the root cause of #642 yet so I
can't say how difficult it may be to accomplish.
> I'd like to see #611 done for the next release (maybe one for me).
I really can't see where this makes sense. <base> can't use a wildcard,
because what would happen if the glob matched multiple directories? For
<file>, it has three uses right now:
<unpack>: it might be useful here, but only if no <reference>s are used,
otherwise it would be illogical
<textdump>: I can't see how it would make sense here
<search_replace>: it could work here, since the search/replace could be
done for each matching file found
> Will #627 ever be considered? Should be removed otherwise. Also applies
> to #640.
#627 is a biggie, probably won't happen for a while. I need to
understand the libxml2 stuff much better than I do now before I can
reasonably comment on it (maybe I'll spend some time looking over the
docs this evening). #640 is debatable whether it has any value.
> #633 needs to be discussed sooner rather than later as more useful
> applications could be produced if a standard was agreed on. I see a
> great perl is-installed script there.
Neven did some work on this late last year as he was working on the
"uninstall" stuff. I don't think we can hold off on a release for it
though, there's too much conceptual stuff to work out first.
More information about the alfs-discuss