Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open
On Thu, Jul 6, 2023 Zoltan Puskas wrote: > I've been following the EGO_SUM thread for quite some time now. One > other thing I did not see mentioned in favour of EGO_SUM so far: > reproducibility. > The problem with external tarballs is that they are gone once the > ebuild is dropped from the tree. Should a user ever want to roll back > to a previous version of an application, either by checking out on > older version of the portage tree or copying said ebuild into their > local overlay, they still cannot simply run an emerge on the it as > they have to somehow recreate the tarball itself too. > While upstream may not host everything forever, it's pretty much > guaranteed to be available for much longer than Gentoo's custom > tarball bundles of dependencies. I see this brought up every once in a while in these EGO_SUM threads, but I think reproducable tarballs are a solved problem, or at least, the tools exist and we just need to decide how to best equip people with them. thesamesam/sam-gentoo-scripts has maint/bump-go which builds these tarballs smartly and reproducably: - use --sort=name to order files inside in a consistent way - use consistent owner:group (portage:portage) - use consistent LC and TZ settings - set a standard timestamp (since 'go mod download' doesn't preserve upstream timestamps anyway, this loses no useful information) With that, multiple developers can independently generate a -deps tarball for a given Go package version with checksums that match. The main distro tarball's checksums are verified against Manifest, and then within it are the list and checksums of the individual downloads which would be verified by go mod download (right?) and the resulting -deps files should also match Manifest entries. So a similar approach could be used in the case of expired ::gentoo versions being installed, or overlays using -deps files without a way to host them. Set things up so this can be done easily on demand or perhaps automatically as needed (maybe through a variation on pkg_nofetch in a Go eclass; that part is not obvious to me). Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
[gentoo-dev] Last rites: dev-ruby/deprecated
# Hans de Graaff (2023-07-06) # Last release in 2012. Upstream is gone. No reverse dependencies. # Masked for removal on 2023-08-06. dev-ruby/deprecated signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last Rites: dev-perl/Gtk2-Notify
# Matt Turner (2023-07-06) # Dead package. No reverse dependencies. # Removal on 2023-08-06. dev-perl/Gtk2-Notify signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Confirm unsubscribe from gentoo-dev@lists.gentoo.org
I wish to subscribe. Proton Mail モバイルから送信 ---元のメッセージ--- 2023年7月5日 22:59 に Chris Frederick が送信: > On 7/5/23 22:58, gentoo-dev+h...@lists.gentoo.org wrote: > > > Somebody (and > we hope it was you) has requested that the email address > be removed from > the list. > > To confirm you want to do this, please send a message to > > > which can usually be done simply by replying to this message. The subject > > and the body of the message can be anything. > > After doing so, you should > receive a reply informing you that the operation > succeeded. > > If you do > not want to do this, simply ignore this message. > >
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On Tue, Jul 04, 2023 at 01:13:30AM -0600, Tim Harder wrote: > On 2023-07-03 Mon 04:17, Florian Schmaus wrote: > >On 30/06/2023 13.33, Eray Aslan wrote: > >>On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: > >>>Why do we have to keep exporting the related variables that generally > >>>cause these size issues to the environment? > >> > >>I really do not want to make a +1 response but this is an excellent > >>question that we need to answer before implementing EGO_SUM. > > > >Could you please discuss why you make the reintroduction of EGO_SUM > >dependent on this question? > > Just to be clear, I don't particularly care about EGO_SUM enough to gate > its reintroduction (and don't have any leverage to do so anyway). I'm > just tired of the circular discussions around env issues that all seem > to avoid actual fixes, catering instead to functionality used by a > vanishingly small subset of ebuilds in the main repo that compels a > certain design mostly due to how portage functioned before EAPI 0. > > Other than that, supporting EGO_SUM (or any other language ecosystem > trending towards distro-unfriendly releases) is fine as long as devs are > cognizant how the related global-scope eclass design affects everyone > running or working on the raw repo. I hope devs continue leveraging the > relatively recent benchmark tooling (and perhaps more future support) to > improve their work. Along those lines, it could be nice to see sample > benchmark data in commit messages for large, global-scope eclass work > just to reinforce that it was taken into account. > > Tim > I've been following the EGO_SUM thread for quite some time now. One other thing I did not see mentioned in favour of EGO_SUM so far: reproducibility. The problem with external tarballs is that they are gone once the ebuild is dropped from the tree. Should a user ever want to roll back to a previous version of an application, either by checking out on older version of the portage tree or copying said ebuild into their local overlay, they still cannot simply run an emerge on the it as they have to somehow recreate the tarball itself too. While upstream may not host everything forever, it's pretty much guaranteed to be available for much longer than Gentoo's custom tarball bundles of dependencies. Regarding space we are also likely making trade-off. By deprecating EGO_SUM we are saving space in the portage tree but in exchange inflating distfiles as it will start accumulating the same dependencies potentially multiple times since now the content is hidden in tarballs containing a combination of dependencies. This is essentially the source file version of "statically linking". Finally a personal opinion: I find dependency tarballs opaque. With EGO_SUM the ebuild defines all the upstream sources it needs to build the package as well as how to build it, but with the dependency tarball the sources are all hidden and makes verification all that much harder. Zoltan
