Planning an overall direction for LFS

Jeremy Huntwork jhuntwork at
Thu Feb 28 20:40:13 PST 2008

Alexander E. Patrakov wrote:
> 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?):


> OTOH, generating a Slackbuild from a spec file seems to be trivial enough to be 
> automated.

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.:

<configure>./configure --prefix=/usr</configure>
<install>make install</install>

Or, perhaps it could be kept in the PHP itself (or Perl or Python or 
whatever is chosen for the server).

Then, depending on which PM a user chose (or if they even chose a PM) 
the proper sort of a spec file can be generated.

I understand that a PM like RPM would need more meta data. We could 
store all necessary information in the spec file, and depending on the 
module chosen, the appropriate tags are used. Unneeded tags are simply 
ignored. For example, a simple tar-based PM method could ignore 
dependency tracking, and manual instructions can ignore everything PM 

I can see the potential for more contribution in this arena, as well. 
Those who prefer a particular PM method should be inclined to help 
maintain that module.


More information about the lfs-dev mailing list