Jan Dvorak wrote:
> Hi,
>
> thank you for your opinions.
>
>> > * Do we want tools to create (or at least verify) builds, pages,
>> > patches..?
>> ...
>
> Chris suggested splitting every build recipe (sed, glibc etc.) to several
> parts like unpacking, patching, build, installation. Patches need some
> explanatory header. It may be desirable to have utilities checking
> correctness
> before submitting these.
You mean like checking, that the patch has a short short comment header
and whether the patch applies (more or less, but preferably more)
flawlessly to the source?
>> building a
>> HLFS system (which would be more of a job for the ALFS)?
>
> Robert wants an early reboot to /tools. It would relieve HLFS from having to
> depend on host non-hardened kernel. For people who do not want a fully
> automated build, but do not have gpm and a web browser it is much more useful
> in a way they can `less` through a script and the execute it.
Do I get it right, that the basic idea is having heavily commented
scripts from which the Book can be generated? For paging through the
script, it might be nice to have something generate ANSI coloured
version (modified rules for enscript would be an option).
As for gpm and web browser: you usually build LFS from a comfortable
distro. Once you reboot, it's perfectly fine to chroot to the original
distro on a number of VTs, so you have both the environment where you
build without depending on the old installation and a fully-fledge
system for anything else during the lengthy compilations (you can even
chroot back into the the booted root, so you can create the HLFS almost
completely from X).
>> > * Have the tools be online? If everything is, it's obvious, but if not?
>>
>> Does it make sense to keep them from general public?
>
> Oh, I meant if we want a neat online syntax checker, or we are just fine with
> ./hlfs-check-recipe. ;-)
As far as I can see, this is question only in case you want to have a
web interface for editing. If email (or later direct repository access)
is OK with Robert, this should not be necessary. Anyone preparing a
change can run it locally before mailing it to Robert (and as usually
under these conditions, patches that do not complete the checking suite
are automatically redirected /dev/null).
>> > * Do we want web interface to submit new things? Is e-mail not enough?
>>
>> svn/git/... access?
>
> Well... you don't give people access to your git repository. Subversion is
> about having a coordinated team. What I meant was, if someone spots a mistake
> in the book, he should be able to fix it and send the fix to be reviewed.
> Plus
> if someone writes recipe to build a BHLFS package, he should be able to send
> it for review too.
Considering the nature of HLFS (that is having a secure system), it
seems to make more sense having someone to review all patches before
applying them to the tree, not just let anyone to apply a fix - no
matter how trivial it may seem. Robert may decide to delegate privileges
for certain parts of the book to other trusted people (AFAIK svn is
capable of this - i.e. allowing access control per directory) but it
should be ensured that nothing "unwanted" gets into the repository.
Kind regards
Petr
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
