Planning an overall direction for LFS

Alexander E. Patrakov patrakov at gmail.com
Fri Feb 29 08:01:20 PST 2008


Jeremy Huntwork wrote:
> I realized that taking such a variable approach as 'choose your own PM' 
> would lead to such issues. The idea I had in mind to solve it would be 
> to make the main spec files nothing more than perhaps very simple xml, e.g.:
> 
> <name>somepkg</name>
> <version>1.2.3</version>
> <patch>file-for-patching.patch</patch>
> <configure>./configure --prefix=/usr</configure>
> <build>make</build>
> <install>make install</install>

Yes, you are working on the important task of defining a common ground for 
package managers beyond this "tar mode". Thanks for this. However, I am not 
really ready to formulate the minimum set of requirements for producing viable 
RPM spec files yet. Of course, RPM-specific crap such as %configure that expands to

   CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
   CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
   FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
   ./configure --host=%{_host} --build=%{_build} \\\
	--target=%{_target_platform} \\\
	--program-prefix=%{?_program_prefix} \\\
	--prefix=%{_prefix} \\\
	--exec-prefix=%{_exec_prefix} \\\
	--bindir=%{_bindir} \\\
	--sbindir=%{_sbindir} \\\
	--sysconfdir=%{_sysconfdir} \\\
	--datadir=%{_datadir} \\\
	--includedir=%{_includedir} \\\
	--libdir=%{_libdir} \\\
	--libexecdir=%{_libexecdir} \\\
	--localstatedir=%{_localstatedir} \\\
	--sharedstatedir=%{_sharedstatedir} \\\
	--mandir=%{_mandir} \\\
	--infodir=%{_infodir}

(i.e., adding implicit ./configure arguments) is out of question. And I don't 
see why <configure> and <build> should be separate tags.

However, it seems that you are solving a wrong part of the problem. Your work 
will allow a _reader_ that doesn't want package management to omit this module 
from the book. However, if package management (even in this simple form) enters 
the book, all editors will have to add such XML _and_ verify it, in order to 
assure quality of their instructions. Such verification, obviously, requires 
using a package manager. I.e., you attempted to solve the problem for readers, 
not for editors.

Of course, one could imagine that general non-PM-aware instructions and XML for 
package management will be written by different people, but what if Randy adds 
yet another Perl module required only by some obscure app? Who will assure the 
quality of packaging instructions? (no offense intended to any party)

-- 
Alexander E. Patrakov



More information about the lfs-dev mailing list