Am Mittwoch, den 08.05.2019, 12:29 +0200 schrieb Pierre Labastie:
> Hi,
>
> After some discussion in an pull request at github [1], it's been decided to
> move the discussion to this list.
>
> Let's first (attempt to) summarize [1]: Jeremy attempted to write a Python
> wrapper to the current jhalfs script, which was working well, but differently
> from the usual jhalfs. So it was first decided to change the code in order to
> have the same behavior as before. That turned out to be difficult without
> adding some ad hoc code, which eventually would have become needlessly
> complicated. It was then decided to start from scratch. I then asked for some
> planning ahead. Jeremy then closed the pull request, and we decided to move
> the planning to this list.
>
> I'd like to propose here a structure for the internal data of the jhalfs
> program. This is open to discussion, of course. In the following, I propose
> objects and attributes to those objects. I do not want to tell how those
> attributes are assigned to, nor how they are used. Just have a data structure
> universal enough so that different types of books can be fit in. Note that the
> following is informal: the aim is to fix where the information should be
> stored, not how (dictionary, list, string, number, ...).
>
> The top object could be 'book', with the following attributes:
> - url (where to find the source)
> - branch-or-tag (when using code repositories)
> - language (for example 'docbook-xml', 'other-xml', 'markdown', 'rst', ...)
> - name (for example 'lfs', 'clfs', 'diylinux', 'blfs', ...)
> - need-user (a boolean indicating whether creating a user is needed for
> running the book)
> - if need-user:
> - username
> - group name
> - environment
> - parameters: for example how to replace <replaceable> tags for 'docbook-xml'.
> Also whether to run the tests, to strip binaries, to remove .la files. Maybe
> break this into several attributes, or have an object for that, or do that at
> the package level (see below)
> - dependency-type: 'ordered' (for example for lfs), 'package' (means each
> package has its own deps), ...)
> - parts: list of 'part' objects, which are described below
>
For LFS in its multilib incarnation it would be great to have an
option to select if, and if yes which kind of ML one want to build.
Currently, beside the REV={sysv|systemd} parameter, one can render the
ML book with a parameter to make selecting the additional arch. That
is ARCH=[ml_32|ml_x32|ml_all|default]:
ml_32 Add instructions to build -m32 libraries
ml_x32 Add instructions to build -mx32 libraries
ml_all Add both oF the two above
default The "stealth" default value used when omitting ARCH= at all
If ARCH=... is omitted (or ARCH=default is set), the result should be
the "original" book without changes.
Maybe thats something which could go in the book class. Future
planning is to add such a ML support to some of the BLFS packages,
too.
> The object 'part' may not be a reflect of the parts in the source book: the
> idea is to break the book into parts that are run in the same environment
> (chroot, run as user, run as root, run after reboot). Note that those parts
> may also be used to sort the packages (such as for blfs, where everything is
> run in the same environment, but parts are needed to make groups of chapters.
> Otherwise, you'll have to choose among 800+ packages in 40+ chapters). That
> is, several parts may have the same environment. Here are the attributes:
> - title
> - how-to-run: 'chroot', 'run-as-user', 'run-as-root', 'run-after-reboot',
> 'mixed' (means "build as user and install as root")
> - chapters: list of 'chapter' objects, which are described below
>
> The object 'chapter' is intermediate between part and page. It's main use is
> to group similar packages (and/or config instructions). Proposed attributes:
> - title
> - pages: list of 'page' objects, which are described below
>
> The object 'page' sometimes has several packages. For example glibc in lfs has
> glibc and tzdata, and several pages in blfs have 2 or more packages (perl and
> python modules, Xorg libraries, fonts, and apps, kde frameworks, plasma, and
> pages with more or less related packages such as poppler). Here are the
> proposed attributes:
> - title
> - type ('single-package', 'multi-package', 'config-only')
> - if single-package:
> - package (see 'package' object description below)
> - if multi-package:
> - packages: list of 'package' objects
> - if config-only:
> - status ('installed', 'not-installed', needed since there is no
> versioning)
> - instructions: list of 'instruction' objects, to be described below
>
> The object 'package' attributes are:
> - id (unique name)
> - version
> - url (list, to be tried in order)
> - tarball name
> - unpack-method ('tar', 'bsdtar', 'unzip', 'other')
> - dependencies: list of couples ('package' objects <-> type), where type is
> 'before', 'after', 'first' (in case there is a circular dep: a package with
> this type should be built first with '-pass1' added to name, then rebuilt
> after)
> - status: 'installed, 'not-installed', 'old-version'
> - needed: one or more of the following: 'basic', 'tests', 'build-doc',
> 'time-size' (for timing and size measurements)
> - instructions: ordered list of 'instruction' objects, to be described below
>
> The object 'instruction' has the following attributes:
> - type: 'config-pre' (e.g.: user creation, directory settings), 'config-post'
> (e.g.: update-icon-cache, various set-up), 'build' (may be refine into
> 'configure', 'make', etc), 'install', 'test', 'build-doc'
> - text (last but not least...)
>
> We may add a higher object: collection, pointing to a group of books, for
> example lfs+blfs, to be able to build lfs+enough of blfs to run jhalfs...
>
> Hope this can make a starting point. Once we agree on this, we'll need to
> write methods to convert some book (maybe a sample book for tests) to internal
> data, and methods to convert our internal data to (scripts+program to run
> them). The program to run the scripts can be a Makefile or something else:
> we'll have to decide.
>
> Regards
> Pierre
> [1] https://github.com/automate-lfs/jhalfs/pull/1
All in all a nice project! Be "carefull" ;-) , such kind of project
leads quickly to some kind of package management tool and the demand
will grow that there is a tool that builds pkgmnt-scripts for it (like
PKGBUILD used by pacman) from the (B)LFS xml files. This in turn will
open another Pandora's box in regards to needed information coming
from the books xmls. That is introducing compiletime dependencies,
setup tasks required run after installing the pkg on target machine
(which maybe different from build machine) and so on...
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
