On May 10, 2009, at 4:11 PM, Eric MSP Veith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> I just got the impression YML was the way to go for you to have a
> for *.spec files. It seemed natural to me, since specs and YML
> already have
> similar looks. I *don't* want any new customized Pimp-my-RPM
> features. I
> just want to know how *you* want RPM spec files to look like, and
> want to
> adopt that. (Even if you're going to choose XML, but I'm going to have
> headaches then.)
Well I'm not sure I'm the right person to ask since
I have a deeply conflicted love<->hate schizo relationship
I know (from a decade of experience) to mess as little
as possible with rpmbuild, too much depends on the behavior,
and life's too short to be lectured at by n00b's who wish
to remind me how important RPM is. I nod and look chagrinned
and remember "I'm shocked! Simply shocked!" lines from Casablanca
Note that *every* time I go to change something in rpmbuild,
I get burned, that's how fragile and poorly designed rpmbuild is.
It's really rather ironic that everyone wants rpmbuild to
stay exactly the same, yet noone is willing to fix the code.
I can count the number of intelligent patches to rpmbuild
that have been contributed on the fingers of one hand. And
at least 3 of the fingers point at PLD ;-) (I might need
two hands, but there have been almost zero contributed
patches to rpmbuild ever).
The most fundamental issue for rpmbuild is answering
What drives a build, a *.spec recipe or a *.src.rpm?
Note that there are build systems of both persuasions around.
The next most fundamental issue is that *.spec files are
being used as a form of "de facto" markup, including, but
not limited to
1) eclipse which has a IDE "spec file writing" module.
2) MacPorts port(1), which is impedance matched to
produce *.rpm packages by using an implict template.
3) rpmrebuild, which takes binary file metadata, writes
a *.spec, and repackages content from a file system
into modified *.rpm packages.
4) The OpenSUSE build system has directives within
spec file comments, ditto PLD.
just to name a few usage cases that are using *.spec files
as "de facto" markup.
The problem with "de facto" is that any rpmbuild change risks voiding
the "de facto" warranty. And so the crappy code in rpmbuild
persists. And if you want markup, well lets do some
serious, not "de facto", markup, many varieties, and actually drive
build factories rather than putting up web pages
about the "proper" way to write spec files with macros.
Note that there is already a xmlspec implementation, basically
rpmbuild, but using XML instead. The implementation was nicely
done, and I carried in RPM for several years until it was absolutely
clear that noone gave a fig about XML.
Note also that I described what I think needs to be done with
spec files at FOSDEM 2005, reprised in 2007. There is no visible
interest (to me) that anyone wants to change anything in rpmbuild.
I can/will lay-out a detailed plan of what I think needs changing;
I have been doing that for years. Its really depressing to find
out that I was saying the same thing 7+ years ago that I say and
think today. OTOH, at least I'm consistent.
73 de Jeff
Received on Sun May 10 23:00:22 2009