On Thu, Nov 26, 2015 at 5:20 AM, Florian Festi <ffe...@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 > implications. > > 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. > > Florian > > 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[0] 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, including scriptlets. 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. [0]: https://abf.io/openmandriva/distro-release -- 真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
