> Three problems with it:
>
> 1. It would be regressive to current functionality for no good reason.
> 2. We don't have a way of distributing this in any kind of reasonable
> fashion through rpm-extras.
> 3. IMO, That's not what rpm-extras is for. It's for staging things to
> eventually integrate into rpm tree.
Negative on 3, that's exactly the other way around. Rpm itself is still
carrying far too much baggage that doesn't belong in it, and these language
specifics are exactly the kind of thing that we're pushing *out* of rpm. Not
because they're inherently bad or anything, but because we are the worst
possible keepers of that stuff, this belongs into hands of people who know and
care about those languages.
As for 1, that's a distro integration issue. We did similar things with 4.15
and the world didn't collapse.
2. is a legit concern wrt rpm-extras though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1070#issuecomment-586864142
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
