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. |