On 08/05/2019 19:00, Thomas Trepl wrote:
> 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.
Thanks a lot for commenting, Thomas,
Actually, this is a refinement of what I called the 'parameters' attribute,
that we should think about: there are a lot of variations also in the CLFS
book (cpu, arch, multilib or pure, byte-order, etc). Whether we'd better make
a book-dependent 'parameter' class, or add attributes to the 'book' class,
hoping they'll cover all the existing books or books to come, I am not sure.
>
>> 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...
>
Hopefully, with a carefully designed internal data structure, writing
back-ends should be easy enough, so that people with specific needs could
write their own. The structure I propose comes actually from my experience
with using porg on BLFS. Hopefully also, people with specific needs may
contribute back-ends to jhalfs...
About compile-time deps, it may not be so important on a system where you
build everything: when something has been built, why not keep it[*]? OTOH,
this information should be taken from the books, and I think if it is there,
it is easy to add it to our internal data... and slightly less easy to write
the back-end :-)
Pierre
[*]: actually, the only package I consider as a compile-only dep is Python 2.
What I do manually after building Python 2 is to put executables out of the
way with:
for i in python python2 python2.7; do
sudo mv /usr/bin/${i}{,.nouse}
done
put them back before each package having P2 as a compile-time dependency:
for i in python python2 python2.7; do
sudo mv /usr/bin/${i}{.nouse,}
done
and removing after. But I use my knowledge of packages in BLFS, since the
information about "compile-time dep" is not in the book.
For the packages really using P2 (AFAICT, asccidoc and mercurial), I change
the #! lines to
#!/usr/bin/python2.7.nouse
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
