Jeremy Huntwork wrote:
> I'm not suggesting that we abandon the bootstrapping method. What I'm
> suggesting is that we make the temporary toolchain into its own module.
Been there (in LeafOS), done that. The non-technical problem is that this
module
(when only its end result is used in a form of prepackaged /tools) needs a good
description, so that it is clear that it is not just a copy of the files you
would find in /usr. This has to mention the modified dynamic linker, library
search path, and similar concepts.
Also there is a technical issue about /usr/bin/nscd being currently linked
against libssp0 from /tools.
> The main LFS module can be about the final system. Teaching users
> _concepts_ of the system, locations of key config files, useful shell
> tricks and tips, information about packages, examples of how to use the
> packages in a practical way, etc, etc. This should make LFS somewhat
> more accessible and easier for end users to pick and choose what it is
> they need out of it.
+1
> The option to bootstrap a temporary toolchain is just an example. But it
> should give you an idea of how we might make LFS a bit modular.
I agree, but maybe some other example modules would make the idea even more
clear.
> To cover PM, we can create a very generic spec file for each package in
> such a way that an end user can either use it in their own custom
> scripts, run the commands manually, or with any number of PMs available.
> To that end, it may be necessary to maintain specific modules for the
> more advanced PMs with directions on how to employ the PM of your choice.
>
> To automate it all, again, when designing the system from the start, we
> make provision to snap-in whichever PM module a user has chosen.
And here is a problem: the chosen PM affects the whole system, i.e., its choice
(unlike, say, the choice of an MTA) is not a local change. And, as you can see,
RPMs and DEBs use very different buildscripts. E.g., RPM finds the shared
library requirements automatically unless told otherwise. In a Debian world,
you'll have your package to depend on ${shlibs:Depends} and insert a call to
dh_shlibdeps with non-trivial flags (e.g., telling that some of the binary
packages, e.g., libvlc0, also come with shared libraries dependencies on which
should be considered) into debian/rules. Thus, I find it impossible to generate
a spec file for RPM and the debian directory for DPKG from the same source
unless both are dumbed down to "tar mode" with external buildscripts
(illustrated by the example below, taken from LSB - do we really want this?):
Summary: A text-based Web browser.
Name: lsb-lynx
Version: 2.8.6
Release: 1.lsb3
Vendor: Linux Foundation
Packager: Appbat Team <[EMAIL PROTECTED]>
License: GPL
Group: Appbat/browsers
Buildroot: %{pkgroot}/%{name}
AutoReqProv: no
PreReq: lsb >= 3.2
%description
LSB conforming version of lynx. Lynx is a text-based Web browser. Lynx
is added to the LSB Application Battery primarly to demonstrate the use
of the ncurses library.
%pre
%install
%post
%preun
%postun
%clean
%files
%attr ( - bin bin ) /opt/lsb/appbat
OTOH, generating a Slackbuild from a spec file seems to be trivial enough to be
automated.
(note the defect in the notes above: they talk only about DESTDIR-based package
managers)
> Generally, I like the idea. A generated book that allows for
> customization and automation in a manner suited to the end user.
Let's try it. At least, it allows to adjust the level of complexity to suit the
reader, which is a good thing (see how I failed to educate CLFS people about
UTF-8).
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
