On 3/30/20 3:00 PM, Nicolas Mailhot via devel wrote:
> On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> Yes, that is an important hurdle that Fedora generally doesn't
>> at all. Fedora usually waits until the new rpm functionality is
>> in older versions of Fedora before allowing it to be used in
Fortunately, that’s not the usual case. Any part of rpm that we refuse
to use, before it is available in older version of Fedora, is a part
that will bitrot and is unlikely to be ever used in Fedora.
Waiting does not make it more stable. Waiting makes sure the people
that were interested in the feature in the first place will move away.
Leaving rpm upstream with an untested feature no one wants to touch.
That would be even more braindamaged than forbidding the use of gcc
features not present in older versions. At least gcc sees some use dev-
side. But who is going to exercise packaging tools if packagers are
forbiddent to use them?
That being said, yes Fedora has been a terrible rpm stackaholder. That
has hurt both Fedora and rpm upstream. Half the NIH reinventing
packaging tools people just can not stand the delays associated with
rpm feature deployments.
Nicolas, thanks for this.
Indeed it's *really* hard (not to mention uninspiring and demotivating)
to develop features in a setting where the first users of said feature
*might* appear years in the future, at which point the feature will
exists in some form in multiple releases already declared stable long
ago, so its impossible to change anything, and even the simplest fixes
would need to go to multiple branches and distros all at once.
So in this setting, with any rpm feature there's precisely one chance to
get things *just* right. We all know how well that works with any
- Panu -