On 08/12/2016 03:17 PM, Jason L Tibbitts III wrote:
"PV" == Petr Viktorin <pvikt...@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.
Thanks for clearing that up, I'm less worried now.
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.)
The macros are definitely of exceptional quality. But, still they're RPM
macros.
(Yes, I have looked SCL macros – that's something I'd not encourage
people to study...)
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.
The idea with pyp2rpm is to work with the Python Packaging Authority so
that the upstream metadata *can* be converted automatically. Ideally
Fedora packagers would fix packaging problems upstream, rather than
maintaining spec files.
Ideas for a tool for *updating* spec files are also floating around.
The idea of pyp2rpm generating spec files using the macros sounds good.
Indeed the projects are more orthogonal than I realized.
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.
Agreed; it would be nice to get to that kind of situation in the future.
Not sure about the lua part, at least while pyp2rpm needs heavy
development :)
--
Petr Viktorin
_______________________________________________
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
