From: "pascal.jaeger leimstift.de" <pascal.jaeger@leimstift.de>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: EGO_SUM
Date: Wed, 31 May 2023 08:30:58 +0200 (CEST) [thread overview]
Message-ID: <1099089481.412152.1685514658082@email.df.eu> (raw)
In-Reply-To: <0e0a773c-ba37-d3f2-bcbc-147252e655c9@gentoo.org>
> Arthur Zamarin <arthurzam@gentoo.org> 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
next prev parent reply other threads:[~2023-05-31 6:31 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 7:37 [gentoo-dev] EGO_SUM Florian Schmaus
2023-04-17 9:28 ` [gentoo-dev] EGO_SUM Anna (cybertailor) Vyalkova
2023-04-27 18:00 ` William Hubbs
2023-04-27 18:18 ` David Seifert
2023-04-24 16:11 ` Florian Schmaus
2023-04-24 20:28 ` Sam James
2023-04-24 22:52 ` Alexey Zapparov
2023-04-26 15:31 ` Florian Schmaus
2023-04-26 16:12 ` Matt Turner
2023-04-26 19:31 ` Andrew Ammerlaan
2023-04-26 19:38 ` Chris Pritchard
2023-04-26 20:47 ` Matt Turner
2023-04-27 7:58 ` Florian Schmaus
2023-04-27 9:24 ` Ulrich Mueller
2023-04-28 6:59 ` Florian Schmaus
2023-04-27 12:54 ` Michał Górny
2023-04-27 23:12 ` Pascal Jäger
2023-04-28 0:38 ` Sam James
2023-04-28 4:27 ` Michał Górny
2023-04-28 5:31 ` Sam James
2023-04-28 6:59 ` Florian Schmaus
2023-04-28 14:34 ` Michał Górny
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:38 ` Sam James
2023-04-29 22:34 ` Robin H. Johnson
2023-04-27 21:16 ` Sam James
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:45 ` Sam James
2023-05-08 7:53 ` Florian Schmaus
2023-05-08 12:03 ` Michał Górny
2023-05-22 7:14 ` Florian Schmaus
2023-05-02 20:04 ` Matt Turner
2023-05-08 7:53 ` Florian Schmaus
2023-04-26 20:51 ` Sam James
2023-05-30 15:52 ` Florian Schmaus
2023-05-30 16:30 ` Anna (cybertailor) Vyalkova
2023-05-31 5:02 ` Oskari Pirhonen
2023-05-30 16:35 ` Arthur Zamarin
2023-05-31 6:20 ` Andrew Ammerlaan
2023-05-31 8:40 ` Ryan Qian
2023-05-31 9:06 ` Arsen Arsenović
2023-05-31 6:30 ` pascal.jaeger leimstift.de [this message]
2023-06-01 4:00 ` William Hubbs
2023-06-02 8:17 ` Florian Schmaus
2023-06-02 8:31 ` Michał Górny
2023-06-09 10:07 ` Florian Schmaus
2023-06-01 19:55 ` [gentoo-dev] EGO_SUM William Hubbs
2023-06-02 7:13 ` Joonas Niilola
2023-06-02 18:06 ` William Hubbs
2023-06-02 18:42 ` Joonas Niilola
2023-06-09 10:07 ` Florian Schmaus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1099089481.412152.1685514658082@email.df.eu \
--to=pascal.jaeger@leimstift.de \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox