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)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7C7FB15806E for ; Wed, 31 May 2023 06:31:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2F146E08C0; Wed, 31 May 2023 06:31:00 +0000 (UTC) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (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 00C70E08AB for ; Wed, 31 May 2023 06:30:59 +0000 (UTC) Received: from [92.51.170.154] (helo=app20-neu.ox.hosteurope.de) by smtprelay01.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q4FMI-0002Ys-60 for gentoo-dev@lists.gentoo.org; Wed, 31 May 2023 08:30:58 +0200 Date: Wed, 31 May 2023 08:30:58 +0200 (CEST) From: "pascal.jaeger leimstift.de" To: gentoo-dev@lists.gentoo.org Message-ID: <1099089481.412152.1685514658082@email.df.eu> In-Reply-To: <0e0a773c-ba37-d3f2-bcbc-147252e655c9@gentoo.org> References: <49ce8700-6c96-9360-51cf-2a989f666752@gentoo.org> <29b2aa18-7498-ad42-757e-fdebad9fa5a5@gentoo.org> <25308876-7ac4-8c90-8641-1034cc67c6b0@gentoo.org> <0e0a773c-ba37-d3f2-bcbc-147252e655c9@gentoo.org> Subject: Re: [gentoo-dev] Re: EGO_SUM 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev43 X-Originating-IP: 212.68.70.3 X-Originating-Client: open-xchange-appsuite X-Originating-Sender: pascal.jaeger@leimstift.de X-Df-Sender: cGFzY2FsLmphZWdlckBsZWltc3RpZnQuZGU= X-Archives-Salt: b71b6415-c4f8-4687-be36-01d85110d2e7 X-Archives-Hash: 81e0d5dd202c5001c7c63923220b6e9e > Arthur Zamarin hat am 30.05.2023 18:35 CEST geschrieben: > > > Currently the best solution *per package* is to speak with upstream, to > add a CI workflow which create a source tarball which includes `vendor` > dir. This is the best way, and I'm doing that for multiple upstream of > some random Go packages in ::gentoo. But I know the disadvantage - > requirement to speak with upstream, explain why, and add it to the > system. This is best long-run solution, but more hardships. > I would like to add to this, that even if upstream is not willing to do this, devs could automate the creation of vendor tarballs using GitHub actions. I only did this for an upstream repositories that are also on GitHub and for projects written in Rust. Initially I did this for complicated Rust projects with several git submodules and submodules of submodules. But with a little tweaking of the GitHub actions I think it would be possible to use it for Go as well. https://wiki.gentoo.org/wiki/User:Schievel/autocreate_rust_sources This is additional initial work, but once you set it up, you don't even have the extra work of creating a new EGO_SUM for every package release. Ideally you just have to change the version in the file name of the ebuild to bump a package. Security wise I do not see a difference between this and creating the vendor tarball manually and uploading it to GitHub, as many proxy maintainers without devspace do it. Regards Pascal