Planning an overall direction for LFS
rcedelman at comcast.net
Fri Feb 29 09:22:24 PST 2008
On Friday 29 February 2008 10:01, Alexander E. Patrakov wrote:
> 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
> (i.e., adding implicit ./configure arguments) is out of question. And I
> don't see why <configure> and <build> should be separate tags.
I agree, any PM-specific macro shouldn't at all be used.
While not all package managers keep configure and build as separate steps (in
fact, I'm not aware of any that actually do have them as separate steps), I
don't see any problems in keeping them separate. They're easily enough
combined into the build() function of pacman, gentoo ebuilds, or any other
package manager that does them in the same step. This way, they'd also be
already separated for anyone that is writing their own PM system in which the
steps are carried out separately.
> 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)
I think the editors should be concerned only with making sure the commands
work in jhalfs or in a copy & paste mode. Perhaps there should be
PM-specific "editors" to verify commands work with their PM system.
Differences in the commands for RPM or Deb could perhaps be in PM-specific
tags like <PM name="rpm"> or perhaps just <rpm>? I'd certainly volunteer for
such a task.
Anyway, that's just my thoughts.
More information about the lfs-dev