[gentoo-dev] Editing RDEPEND without a new revision (again)

[Michael Everitt]

On 25/10/19 14:43, Michael Orlitzky wrote:
> On 10/24/19 10:03 PM, Michael Everitt wrote:
>> Forgive my lack of git-fu, but which commit did this? Can we name & shame
>> the author and committer publicly, and in front of QA, so that this kind of
>> violation is highlighted to all, and noted for future reference?
>>
> I left it out on purpose. This isn't a one-person problem, and my anger
> isn't only targeted at the last person who was unlucky enough to do it
> right before I snapped and wrote the email.
>
> This comes up on the -dev list several times a year. We've fought about
> ecosystems adding dependencies to stable packages via eclass USE flags.
> We fight about the revision policy in the devmanual. We've been fighting
> about dynamic dependencies in the package manager for 10+ years. The
> portage team basically quit once over this. A few years later we fought
> about it again and finally turned them off, but the commit got reverted
> when users complained that developers were constantly breaking things.
> That contributed to a fork of the package manager...
>
> Point is, it's not a new thing. And it's a huge waste of time for
> everyone involved. It's also simple to avoid. Just make a new revision
> when you change something. You shouldn't be changing stable ebuilds
> *anyway*, but if you're already going to violate that policy, it doesn't
> do any more harm to move it to -r1 in the process.
>
I think the policy on this in the devmanual/etc is a little too vague. My
impression is that changes to an ebuild which make a material difference to
the files installed, should definitely be rev-bumped, but certain other
changes, and bug fixes, don't need this as they result in missing
functionality being rectified/restored.

Personally, because I have yet to see any revbumps beyond about -r5 I don't
think we would have a problem in reality if everyone bumped the revision
*regardless* on *any* change, and we dealt with the consequences *that*
way. When/If we get to -r99 on a package perhaps we can revisit this topic,
and why so many updates are necessary to a "stable release" (!).

I sense that the problem boils down to a lack of 'warm bodies' and people
making poor decisions or lazy decisions because of a need to move something
forward, without properly considering the wider implications of their
'shortcuts'. This isn't a problem likely to be solved soon, however, and
becomes a meta-problem of another sort.

However, I'm noting a number of quite angry posts arriving on the public
lists, because we have Hard Problems that are creating issues for those
attempting to contribute. I think that if you find you're reaching this
threshold, perhaps its time for you to take a break, get some air, and
consider whether you have the resources to fix the underlying problem, or
whether you can tolerate the status quo. Nothing is going to change fast,
and will likely require a lot of compromises on the way. That said, there
is no harm in trying new things, and accepting that some ideas may have to
be reversed. But let's not continue to throw too many daggers across the
lists, as it doesn't do anybody any favours, beyond venting frustrations.

</my2cents>