Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: dev-portage <dev-portage@g.o>
Subject: [gentoo-dev] [RFC] Removing obsolete thick Manifest compatibility from MetaManifests
Date: Thu, 24 Oct 2019 12:37:34
1 Hello,
3 TL;DR: I'd like to disable thick Manifest support in Portage, in order
4 to disable some of the compatibility quirks from MetaManifest format.
5 All files would still be verified by gemato.
8 We're using GLEP 74 MetaManifests for 2 years now. The specification
9 was originally written to account for compatibility with existing
10 (thick) Manifest files. I believe we can start considering removing
11 at least some of that compatibility today.
13 What I'd like to propose is disabling thick Manifests in the rsync
14 variant of Gentoo repository (in layout.conf). This would cause Portage
15 to stop verifying file entries directly (on-sync verification via gemato
16 would still happen). Notably, this would limit the needed compatibility
17 to DIST entries.
19 Why?
21 1. Thick Manifest verification happening in Portage is mostly redundant
22 these days, and when it's not its advantages are weak.
24 1a. Majority of Portage users are using on-sync verification via gemato.
25 In this case, repeated partial checks from Portage are at most
26 redundant.
28 1b. While not using gemato, Portage verifies only leaf Manifests without
29 checking the OpenPGP signature. There's no real security gain in this.
31 1c. With transmission-level checksumming (and filesystem-level checksums
32 becoming more common), there is no reason to assume we need to verify
33 integrity of rsync result.
35 2. Thick Manifest support in Portage is still relying on legacy entries.
36 While technically we could either make Portage use gemato fully, or
37 reimplement the new features, I don't think it's worth the effort given
38 the above.
40 2a. Removing legacy entries from ::gentoo will make it possible to
41 remove the backwards compatibility code from gemato. We may also remove
42 some of the redundant code from Portage.
44 2b. We will gain the ability to use the new format more efficiently.
45 In particular, I'm considering moving non-DIST entries to category-level
46 Manifests and taking advantage of compression (but I don't know if it's
47 going to provide real gain at the moment).
49 3. Thick Manifests are generally PITA to power users and developers.
51 3a. You need to regenerate them every time you edit an ebuild. It's
52 like having to type 'yes, I really wanted to edit that file' every time.
54 3b. You need to regenerate Manifests when moving ebuilds between git
55 and rsync checkouts.
57 3c. Proxied maintainers keep forgetting about that and submitting thick
58 Manifests.
61 WDYT?
63 --
64 Best regards,
65 Michał Górny


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