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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page