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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B59BA138334 for ; Thu, 5 Dec 2019 22:00:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 095FAE0948; Thu, 5 Dec 2019 22:00:41 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6CA94E093B for ; Thu, 5 Dec 2019 22:00:39 +0000 (UTC) Received: from [IPv6:2a01:e34:eeaa:6bd0:52d3:51dd:1b2:5ddb] (unknown [IPv6:2a01:e34:eeaa:6bd0:52d3:51dd:1b2:5ddb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id EC71A34D811 for ; Thu, 5 Dec 2019 22:00:36 +0000 (UTC) Message-ID: <31d2646b48bc35d02ca2a7a0b9db7b634d5b0ef0.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Date: Thu, 05 Dec 2019 23:00:32 +0100 In-Reply-To: References: <20191205160957.576971-1-mgorny@gentoo.org> <067cc5678d1eb4a3445bdf7beefe8c055307eeb4.camel@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: f7f8d9de-1e2e-418c-8dce-01c64ea0bc6c X-Archives-Hash: 63e83d9fdaf7265b361d82688ad208e3 On Thu, 2019-12-05 at 19:04 +0100, Michał Górny wrote: > On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote: > > On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote: > > > On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote: > > > > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote: > > > > > +############################################################ > > > > > #### > > > > > #### > > > > > +# > > > > > +# This file specifies packages that are considered > > > > > deprecated > > > > > (but > > > > > not > > > > > +# masked yet). It will trigger pkgcheck warnings whenever > > > > > other > > > > > +# packages depend on them. > > > > > > > > > > > > > repoman would be more useful for this > > > > > > > > > > Then feel free to take repoman over, and start maintaining > > > it. I've > > > lost interest in contributing to the project after the last > > > pointless > > > refactoring made adding anything even more effort, and it doesn't > > > seem > > > that anyone else has. > > > > > > Given that pkgcheck is a. faster by design, b. running checks > > > in parallel, c. has sane API making contributing a pleasure, I > > > don't > > > really see a point in putting any more effort to support a dead > > > repoman. > > > > > > > it's not about who's maintaining what here... > > just s/pkgcheck/QA tools/ and be done with it > > Oh, I've listed pkgcheck there because it's the only tool > implementing > the file at the moment. I'm happy to replace it with larger list or > something more generic once there are other tools. However, I > believe > that saying 'pkgcheck' right now has the advantage that devs know > which > tool to use to see the result. IMHO maintaining such a list is better suited for devmanual or wiki; just like skel.ebuild could be improved by removing portage references and refer to PMS > > pkgcheck is mostly used by your CI checks for > > producing huge reports, which is nice but addresses a different > > problem > > There is nothing stopping you from running pkgcheck locally. In > fact, > it should work out of the box these days. If you have any problems, > please report them and I'm sure they will be addressed promptly. Sure I did that to get reports like what CI does for me now but that's always been a different usecase; I wasn't aware pkgcheck had the equivalent of repoman commit > > i could see this file being useful for auto-generating lists on qa- > > reports like for eapis too > > I don't think there's really a point in duplicating this. For now certainly not. Once someone wants to wipe a deprecated package this could come in handy instead of searching a huge html page, but sure this could be fixed the other way by having this in the per-check reports like what is on the left side of the current CI reports