To Jeremy Huntwork, his team(s), his project(s), his supporters and staff.
gmakmail at gmail.com
Mon Aug 6 09:31:49 PDT 2007
On Thursday, 02 August 2007 02:06:04 am Jeremy Huntwork wrote:
> The libxml and libxslt stuff could be dropped if we were to make use of
> a C or C++ based parser. I know George M. was working heavily on a
> solution, but I don't know his current status. The one that is in the
> alfs-POC works well enough (I'm sure there's bugs that need to be fixed,
> but it was working last I checked.)
With a bit of delay, a public reply to Mr. Jeremy Huntwork with the most
noble of intents.
First of all I would like to thank you for remembering my contributions
despite inter(active)net eons have passed since last year, and we have not
talked about it since.
The approach I have been working on, single - handed, and in complete
_ob_scurity since the advent of certain issues, is now totally completed in
its design, extendibility and C++ based implementation. Parts of it have
found their way into the alfs-POC SVN (and _not_ viceversa) in the past, as
stated by you (Jeremy Huntwork) in various occasions.
Believe it or not, I am able to build what I was set out to build with it;
and yes, UTF-8 is not a problem at all, or any other encoding for that
matter. Neither are many other things that will eventually emerge for you
in here. And it also has _no_ external dependencies whatsoever.
For the sake of completion, I will simply re - post a particular part of
older code, as it was posted in the mailing list after a rather unfortunate
series of events. I have talked to you about it Jeremy H., you do remember
when, how, where, with what and for what, right? It was dubbed "xnzyme". I
have given that name up since then.
The interested reader can find many other POC (and not so POC..) within the
alfs mailing list spanning both as bash - based(with their obvious pitfalls
for when the project management was _convinced_ that bash was all that was
necessary) and C++ std::string based ones (std::string was used for the
commodity of implementation, for it is unsuitable for the task beforehand
given its limitations) posted by yours truly.
Therefore I consider the link below useful point of reflection regarding how
some things may, and most importantly may not (to the trained eye) be done:
To date, that was my last reply ever to *lfs and *lfs related lists. Further
details can be seen there and here.
I wish to everybody good luck for _their_ particular *lfs automation
framework implementation in their language of choice. It is possible that
something better than Portage / Paludis - based Gentoo, Sourcemage,
Archlinux, T2, Lunarlfs, etc can emerge from these lists and eventually
enter the perennial circle of cross - pollination among GPL projects.
Concerning my personal project, I will eventually release a _GPLv3_ (three)
licensed version of the entire project I have been working on, when
_circumstances_ will be mature for it.
The project treats the problem of automation in general when building
distributions from source, therefore it cannot be considered an
*lfs/derivate contribution for it is to share very different goals with the
automation infrastructure as it is to be built for *lfs/derivative by
official lfs contributors. It will have its own little spot in the
inter(active)net, its own Mercurial repositories etc.
I would like to thank the many people who emailed me during this period
(readers and non of these lists), requesting information for both bash -
based and C++ - based concepts regarding the aforementioned attempts.
Cursum Perficio. Age quod agis.
More information about the alfs-discuss