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?):
[snip]
> 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.:
<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>
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
related.
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.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
