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

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

[Michael Orlitzky]

Here we go again. All week I've been trying to update @world. I'm trying
to troubleshoot a portage bug[0], deal with portage taking forever to
fail, and now I've got to deal with the fact that someone was too clever
to follow the PMS and replaced virtual/pam with sys-libs/pam across the
entire tree (and immediately masked the package that we all have
installed) without creating any new revisions.

Thanks to the aforementioned portage bug, I can't follow the non-PMS
suggestion to update everything with --changed-deps. So I either have to
live with the fact that I have a masked package (virtual/pam) installed
-- which pisses portage off and makes it impossible to troubleshoot my
dependency resolution problem -- or try to uninstall it and then resolve
the rebuilds myself. This is how that goes:

  $ time emerge -puDN --tree @world

  These are the packages that would be merged, in reverse order:

  Calculating dependencies... done!
  [nomerge       ] net-print/cups-2.2.12
  [ebuild  N    #]  virtual/pam-0-r1

  The following mask changes are necessary to proceed:
   (see "package.unmask" in the portage(5) man page for more details)
  ...
  =virtual/pam-0-r1

  NOTE: The --autounmask-keep-masks option will prevent emerge
        from creating package.unmask or ** keyword changes.

   * In order to avoid wasting time, backtracking has terminated early
   * due to the above autounmask change(s). The --autounmask-backtrack=y
   * option can be used to force further backtracking, but there is no
   * guarantee that it will produce a solution.

  real	4m37.909s
  user	4m35.287s
  sys	0m1.437s


Now I re-emerge cups, and try again. Then net-fs/samba fails. Then
sys-libs/libcap fails. Then sys-apps/shadow fails. Then
x11-themes/slim-themes fails. And so on. These are all things that I
have to sit in front of the keyboard for 4m37.909s, time and time again
to deal with, all because RDEPEND was changed without a new revision.

That's it, that's all I did for Gentoo today. I started out at 8am
trying to fix two bugs, and I spent all of my free time today unfucking
my system. Now it's 6pm and I'm out of time with nothing accomplished. I
haven't even found all of the packages that I need to rebuild yet, so
this is where I'll start again tomorrow, too.

And it's not like this is a rare problem. Please, just follow the damned
PMS and make a new revision when you change dependencies. It's not much
harder to do things right, so cutting corners and wasting my whole day
is pretty selfish. And as a bonus, the people who don't use portage
won't think you're an asshole for telling them to fix the problem by
using portage.


[0] https://bugs.gentoo.org/698232

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

[Michael Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]

On 24/10/19 23:04, Michael Orlitzky wrote:
> Here we go again. All week I've been trying to update @world. I'm trying
> to troubleshoot a portage bug[0], deal with portage taking forever to
> fail, and now I've got to deal with the fact that someone was too clever
> to follow the PMS and replaced virtual/pam with sys-libs/pam across the
> entire tree (and immediately masked the package that we all have
> installed) without creating any new revisions.
>
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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Fri, 25 Oct 2019 03:03:26 +0100
Michael Everitt <gentoo@veremit.xyz> 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 think you can blame zlogene.

I didn't use git-fu, I just searched my email logs of gentoo-commits ;)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db5beca3

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Orlitzky]

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.

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

[Michael Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3255 bytes --]

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>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]