From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EFEAD15808B for ; Sat, 12 Mar 2022 02:53:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 000052BC003; Sat, 12 Mar 2022 02:53:14 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1619FE0922 for ; Sat, 12 Mar 2022 02:53:13 +0000 (UTC) Subject: Re: [gentoo-dev] Deprecating repoman To: gentoo-dev@lists.gentoo.org References: <8833532d-317c-6f9e-cec9-d6f03ff71135@gentoo.org> <8ff5dd6c-0f9a-3a17-a53d-527c23d46892@gentoo.org> From: Joshua Kinard Message-ID: Date: Fri, 11 Mar 2022 21:53:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: ade1a690-1c3a-4182-8e14-9cab701017cb X-Archives-Hash: f9f4907cd36948084decb7e08ce42f1e On 3/11/2022 20:57, Sam James wrote: > > >> On 10 Mar 2022, at 23:18, Joshua Kinard wrote: >> >> On 3/10/2022 14:58, Alec Warner wrote: >>> On Thu, Mar 10, 2022 at 10:27 AM Joshua Kinard 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 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@gentoo.org 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