>>>> "PV" == Petr Viktorin
<pviktori(a)redhat.com> writes:
PV> The magic worries me. It seems like if these macros were finished,
PV> you'd be about the only person capable of maintaining them.
I don't think so. There are other committers, and the core of it didn't
even come from me so there's certainly at least two other people around
who can handle this stuff. It's true that not a whole lot of people
understand the deeper interactions between the RPM Lua interpreter and
the rest of RPM, but it took me only about two days to figure out most
of it _without_ having any documented examples. And I have a real job
that isn't Fedora.
The macros are very well commented; the magic is described in detail.
They also include a debugging framework. Which is more than, well, any
other current macro magic. Ever tried to debug debuginfo package
generation? Or even looked at the SCL macros? (Which are about on par
with magic-ness, but which are completely unreadable and have no
debugging.)
PV> And if something goes wrong (magic tends to imply fragility), I'm
PV> not looking forward to the debugging sessions. So, while I am blown
PV> away by this project, I'm inclined to place my bets on pyp2rpm
PV> instead.
Well, there's no reason not to have more than one solution. However,
pyp2rpm just gets you a spec. You still have to maintain said spec, and
wiping it out with a fresh run of the generator is not really
acceptable. I'd generally argue that pyp2rpm would actually generate a
spec using this stuff, once it's actually proven that it works.
I would still like to have the spec file be simply an intermediary
between some metadata and the build system. Or, if you can write
pyp2rpm in lua, I could actually build it directly into rpm. Have the
regular RPM header, then a %prep section that unpacks the source and
calls a macro. The rest of the spec (except the %changelog section) is
simply generated from the metadata.
- J<