[Rpm-maint] [rpm] initial embedded python interpreter support (@rpm5.org derived) (#25)
ngompa13 at gmail.com
Sat Nov 28 13:37:28 UTC 2015
On Thu, Nov 26, 2015 at 5:20 AM, Florian Festi <ffesti at redhat.com> wrote:
> On 11/19/2015 04:09 PM, Vít Ondruch wrote:
> > What is the usecase for this? Isn't this just feature bloat?
> I kinda agree that this looks like feature bloat. This patch set needs a
> very good justification to go in upstream. The overall trend is to
> rather keep minimal installs smaller as this is a big issue for
> containers and VMs. Python is one of the candidates to be thrown out at
> some point.
> Also embedding a particular version of Python into rpm itself makes this
> Python version part of the spec syntax with all kind of possibly ugly
> It also seems to not bring many benefits except from saving the
> interpreter starting time (which can be significant if there are many
> Python scriptlets). But the trend here is also to rather getting rid of
> more of the scriptlets using the new file trigger feature (We'll see how
> this works out).
> Having access to the transaction objects of the running rpm instance
> could give such justification as it can hardly done in any other way.
> But I really, really doubt that we wan to go down that route. Especially
> as it gives a whole new way of how scriptlets can break a transaction.
> As the patch set is not interfering with many places in the rpm code it
> should be not too hard to maintain the changes outside of the upstream
> repository for distributions with (still) rely on this feature.
So the main justification for the Python stuff is less about scriptlets
and more about being able to have templates for spec files. In
OpenMandriva, for instance, the distro-release package includes a
Python script that is used by the main spec file at build-time (not
run-time!) to construct the complete spec customized for a particular
distribution (as there's actually at least three different distributions
hosted and built through OpenMandriva's ABF system). There's no really nice
way to do this with the existing RPM feature set.
The ways I've seen this done in the absence of this feature (and I have
seen it attempted a few times before) are pretty terrible. It's usually a
combination of macros, bconds, and a whole bunch of other crazy things to
make it work, and it's an unmanageable mess.
Most of the usage of this feature is centered about the build-time
availability rather than the run-time one (in fact, the run-time
functionality is horrifically broken in rpm5, from what I can tell).
However, *I* don't want this code to go in without *everything* working,
Perhaps if it was actually possible to maintain as an actual RPM plugin, it
could be maintained as such. I believe Per Øyvind Karlsen is trying to make
it as non-invasive as possible so that it *could* be as much like a plugin
as possible. However, maintaining it as a plugin isn't really possible
because it *does* amend the spec syntax.
This feature would also likely be a candidate for being disabled by default
rather than enabled, since it's not particularly useful for anyone unless
they actually have a goal of making it easier to create spec templates
where you can tweak a few things and customize it that way. Not a lot of
distributions want to go out of their way to make it easy to do that.
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint