On Sep 8, 2008, at 1:13 PM, Bernhard Rosenkraenzer wrote:
On Monday 08 September 2008 00:01:27 Jeff Johnson wrote:
Yes I hear how hard spec files are to write on a daily basis.
Ok, let me tell you the opposite then. ;)
;-)
The main reason why we picked rpm over dpkg or the likes when we
started Ark Linux was that spec files are so much easier to write (and
especially to learn) than Makefiles, dpkg control files, and the
likes.
The good thing about spec files the way they are is that pretty much
anyone who knoes how to compile an application in a shell prompt
(which is still almost any linux user) can write a spec file.
We have a few "package monkeys" who don't know anything about
programming and who know only the basics of shell scripting, but
they can build rpm packages just fine.
I can see why a more experienced developer may prefer writing a
Makefile or the likes (which is probably where you get the complaints
from developers coming from other OSes -- the average Windoze
user thinks it is confusing that a shell prompt doesn't start with C:
\>,
but loves writing MSVC project files that make no sense at all to
people using a real OS) - but let's keep the package monkey
interface around too...
Please note that I'm suggesting an alternative, not a replacement, to
existing
*.spec files.
Interfacing a build factory to rpm packages and spec files is a whole
different
problem space than what "package monkeys" (like me) have been doing
for years.
The means by which modern build factories are attempting to generate
*.rpm
packages for distribution show how *.spec files aren't the most useful
representation.
Here are some examples from what I consider "modern build factories"
OpenSUSE is providing useful extensions in spec file comments.
PLD is adding build element digests in spec file comments.
Note comments. And the flaw is in RPM spec files, not with either of
the above efforts.
There is also increasing need to build from "exploded source trees" as
suggested
by Doug Ledford, and also consistent with what I'm seeing with a
traditional make(1)
*BSD "make world" build system. The means by which information is being
extracted from spec files, and how spec files are used as a templating
language
for build factories are what needs to change.
So I'm suggesting alternative representations, in this case by
converting the *.spec
build scriptlets to make(1) rules, eliminating macros and other
parameterization.
I'm mostly certainly not suggesting replacing the existing spec files.
73 de Jeff
ttyl
bero
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
