Gentoo Archives: gentoo-dev

From: Sam James <sam@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: dev-portage@g.o
Subject: Re: [gentoo-dev] Current portage will now truncate your repo's git history to 1
Date: Sat, 17 Dec 2022 05:43:02
Message-Id: BA316A69-710C-453F-A6DE-880D98AD727D@gentoo.org
In Reply to: [gentoo-dev] Current portage will now truncate your repo's git history to 1 by Florian Schmaus
1 > On 15 Dec 2022, at 19:22, Florian Schmaus <flow@g.o> wrote:
2 >
3 > This is a public service announcement that the recently stabilized portage version will truncate you repo's git history to 1.
4
5 I wish you'd shown us in #gentoo-portage before sending this, as it's a bit misleading / alarmist. We were actively all speaking
6 at the time.
7
8 Not only to reconsider the phrasing and include some important details, but also to mention the rationale, which I describe
9 below.
10
11 If you felt the Portage team should've written a news item for it, you were (and still are) free to say so, and we'd
12 do it.
13
14 >
15 > While this is a good thing for the majority of Gentoo users, it affects developers that develop in a git known to portage (like me). If I understand the portage maintainers vision correctly, then future portage will assume full control over its configured repositories and potentially perform destructive operations on them, for example "git clean" [1].
16 >
17 ... only for repositories of sync-type=git & auto-sync=yes.
18
19 The rationale for this is that most people who use sync-type=git are doing so because they want
20 a quicker sync (to complete), a more reliable one (no Manifest race condition issues), and to
21 get changes from Gentoo faster.
22
23 Whenever Portage is syncing something, our view was that we should prioritise successful
24 completion of syncs, especially given it may be performed unattended.
25
26 If git is pulling from a CDN, Portage may on one sync receive state X, but
27 on a subsequent sync receive state X-1. This can cause an odd state
28 where git wants to resolve conflicts and manual intervention is required.
29
30 This situation was often worse with sync-depth=1 and would lead
31 to orphaned files, hence the 'git clean' PR referenced.
32
33 The motivation behind the sync depth part was because of
34 disk space growing unbounded otherwise.
35
36 > I personally would prefer portage simply adjusting its behavior based on the owner of the repository. That is, if it's the 'portage' user then assume full control, and if it is a different user, then fall back to a preserving, conservative mode of operation. Unfortunately, for me, this idea was received skeptically at best in a recent discussion in #gentoo-portage.
37
38 This wouldn't work for Prefix and also FEATURES="-usersync".
39
40 --
41
42 Now, looking forward in a constructive manner, I think we can
43 make both camps happy here with an option to indicate
44 If Portage can assume the repository will be touched by something
45 other than Portage.
46
47 I propose a configuration option called 'volatile' (thanks
48 Arsen for the name suggestion) which indicates that the
49 repository may be changed outside of Portage by any time,
50 and hence no destructive operations should be carried out.
51
52 If the option is on, it also prohibits some optimisations
53 which require assuming the integrity of the repository.
54
55 I have a draft of these changes at https://github.com/gentoo/portage/pull/961.
56
57 (https://github.com/gentoo/portage/pull/961.patch if want to view as a raw patch series.0
58
59 I am undecided on whether volatile should be default on or not. In the PR
60 as it is, it defaults to off, which would require a news item. I may just turn it
61 on given the tone of this thread, as none of it has been very encouraging
62 for further work on Portage.

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies