Re: [gentoo-dev] Deprecating repoman

[Joshua Kinard]

On 3/11/2022 20:57, Sam James wrote:
>
>
>> On 10 Mar 2022, at 23:18, Joshua Kinard <kumba@g.o> wrote:
>>
>> On 3/10/2022 14:58, Alec Warner wrote:
>>> On Thu, Mar 10, 2022 at 10:27 AM Joshua Kinard <kumba@g.o> wrote:
>>>>
>>>> On 3/9/2022 16:00, Matt Turner wrote:
>>>>> I'd like to deprecate and ultimately remove repoman. I believe that
>>>>> dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts)
>>>>> are far superior replacements, and it makes sense to have people using
>>>>> the same tool and seeing the same warnings as in the CI.
>>>>>
>>>>> Are there any useful checks or behaviors of repoman that are missing
>>>>> from pkgcheck and pkgcommit?
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>
>>>> repoman has been //the// goto tool for checking in a change since before I
>>>> was a developer in 2003.  It does everything we need, in one simple tool.
>>>> Your proposal looks to replace repoman's functionality (and snark) with two
>>>> or more packages, including tools from a package named after a fellow developer.
>>>>
>>>> Additionally, "I believe that <foo> are far superior replacements" is an
>>>> entirely subjective opinion and, frankly, completely invalid as
>>>> justification to replace a tool that has worked fine for the last 20+ years.
>>>> What is so fundamentally broken about repoman that cannot be fixed such
>>>> that it needs total replacement by multiple independent tools?  Please
>>>> document. the pros and cons here so that we can all make an informed decision.
>
> Matt could've given more details about why pkgcheck is superior but I think
> this is actually showing/exposing the problem again: we've assumed that
> everybody should really know repoman lacks a significant number of the checks
> pkgcheck has, as well as being much slower.
>
> Those are the two reasons why it's superior.

But again, those are subjective observations.  Maybe it's my longer
experience with the project, or maybe it's because I usually refrain from
poking the more complex bits in the tree, or maybe it's the particular niche
I've stuck to, the extra checks that pkgcheck runs haven't really applied to
me.  If I do too many significant changes to an ebuild, I'll re-read its
source a half-dozen times or more to make ***sure*** that I didn't miss
something.  I will grep the tree for similar bits of code to make sure I'm
doing something reasonably sane, I will test that ebuild on at least two
different arches (amd64 and mips), etc.  Maybe I over think it, or maybe I
have some form of hyperpedanticism.  Or maybe I've just been really lucky.
:: shrugs ::

And speed, again, is really quite far down on my list of concerns most of
the time.

That said, yes, I agree with you wholeheartedly that there was a failure at
the Project/Distro level to explain the benefits of using pkgcheck over
repoman scan/full.  That's a communications failure, and it is really
symbolic of a larger issue that projects like ours often struggle with.
Each of us tends to operate off in their own little fiefdom, something I am
just as guilty of as anyone else, and we don't always know what other devs
are doing or how they're doing it.  I wish I had suggestions to offer up at
the moment on fixing this, but, alas...


>>>
>>> So here is the more basic argument, you can agree or disagree.
>>>
>>> *The goal I want is for people to commit to the tree and not break things.*
>>
>> This goal I agree with, and I am rather pedantic about.  If not mildly
>> fearful of.  We've all been there at least once in our dev-lives.  It's
>> almost a rite of passage, if you will, to break the tree with a dumb commit
>> at least once.  Goal is to never repeat that mistake again.
>>
>
> Right. I spend a fair amount of time fixing issues with repoman doesn't
> find but pkgcheck / CI does, or filing bugs for them.
>
>>
>>> If we could accomplish this with no tooling at all, that would be
>>> great. Sadly humans are fallible and so we have tools to check their
>>> work. Currently this tooling has two parts:
>>> - pre-push tooling that you run prior to pushing.
>>> - post-push CI tooling that informs you when you break the tree.
>>>
>>> So holding to our goal of not breaking the tree, it's better for
>>> developers to run the same QA tool in pre-push that CI is using,
>>> because our metric for 'breaking the tree' is the CI tool and if the
>>> CI tool passes locally, there is a strong likelihood it will not break
>>> in CI either. Note this argument is generic, I'm not even saying which
>>> tools are in use, or which tools are better, or anything like that.
>>>
>>> Here we see Matt discussing a workflow he finds frustrating.
>>> - A developer does a push.
>>> - Their push breaks CI.
>>> - He inquires about their workflow.
>>> - He learns they did not run the CI tool in their pre-push workflow.
>>> - He tells them they should run the CI tool in their pre-push workflow.
>>> - This happens many times, causing this thread.
>>>
>>> The point of the thread then is to convince people to run the CI tool
>>> in pre-push, as a matter of policy, to reduce tree breakage and reduce
>>> the occurrence of the above conversation.
>>
>> I stick to the officially-published method of checking and committing changes:
>> https://devmanual.gentoo.org/ebuild-maintenance/git/index.html
>>
>> The two tools highlighted there for the bulk of the work is repoman and
>> pkgdev.  repoman is cited twelve times, pkgdev is cited six times.  pkgcheck
>> is mentioned once.  pkgcommit has no mentions.
>
> pkgcommit is just a wrapper around git and pkgcheck, so it is there.
>
> It's not like you aren't allowed to make your own wrappers or aliases or scripts, right?

Yes, I could.  but that's not the point I was making.  My point was Matt
recommended pkgcommit as one of the two tools deemed superior to repoman,
but without providing any context.  TBH, I didn't even know that the
containing package was even in the tree, and I certainly didn't even know
pkgcommit existed.  I made the point I did about there being no mentions of
pkgcommit in that part of the devmanual to underscore that fact.

I've got my own small (but growing) collection of trashy little hackscripts
(and a collection of aliases) for maintaining my Gentoo and BSD systems.
Many of them are so specific to things I do locally on my machines, they're
never going to wind up published anywhere, because they likely won't work
for anyone but me.


>>>
>>
>> Back in mid-2002, it was exactly Gentoo's snarkness that tipped the scales
>> for me.  I'd just given up on FreeBSD-4.x on a sparc64 machine (old Sun
>> Blade 100) and LFS turned out to not be a lot of fun, but Gentoo worked fine
>> on it.  All of the colors on the terminal gave it zing and pop, and made it
>> rather fun to work with.  rpm and apt-get were dull;  emerge was cheeky and
>> playful!  Still is to this day.
>>
>
> I have no objection to (and in fact would rather welcome) contributions
> to make other tools more "Gentoo-like". Could you make a PR or provide
> some patch to add some more personality to them?

Unfortunately, I have been advised by many of my friends and associates to
stay well away from anything remotely resembling comedy.  Like many people,
I get the jokes and laugh along with them, but like a Vogon reading poetry,
I should never attempt to create the jokes.  I get away with the small pun
here and there, but it's only a matter of time before the gallows will find
me for one of those.

And really, much of Portage's built-in humor is largely a function of
carpaski being one of its original authors.  He's even got his own Urban
Dictionary entry, which should tell you a lot about things:

https://www.urbandictionary.com/define.php?term=carpaski

Honestly, see that entry brings back a lot of memories...

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic