Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] [Patch] Repoman rewrite stage2 modularization conversion complete
Date: Sun, 10 Jan 2016 21:41:03
1 I have now pushed a fully rebased, properly sequenced commit history
2 to the repoman branch. To be honest I think all the rebasing,
3 re-testing took as much time as the initial conversion and testing.
4 Anyway, I consider the branch now ready for final review. Since there
5 are a total of 45 commits. I am not sending them to the list at this
6 time. They are available for review via the repoman branch at
12 or github pull request for commit order convienience
16 But please try to follow our standard rules and reply with any comments
17 or code review to this email thread. I can also generate the email
18 patches if necessary, but I fear they will just clog up your inbox.
19 There are some patches that are quite large like the vcs plug-in
20 conversion which could not be done piecemeal and still be able to run
21 the code to test.
24 Summary:
26 This stage now has three plugin system loops to process all the checks
27 and maintenance actions. The three loops are currently hard-coded and
28 many of the checks must be run in a certain order as many of the
29 checks add or modify the dynamic data required by later checks. I
30 will endeavour to create a complete wiki page on the new system when
31 approved, detailing how to create modules. I will also generate a
32 table of dynamic data available and the modules responsible for
33 it. In that way any modification to the modules run, added or removed
34 can be determined.
36 1) Primary pkg level checks
37 2) Ebuild level checks
38 3) Final pkg level summary checks
40 There are 2 primary plugin systems
42 1) The VCS plugin system
43 2) The Scan plugin system
45 All use the existing portage plugin system used in emaint and the new
46 sysnc systems.
48 The scan plugin modules can have functions that run in any of the three
49 loops. They can also have more that one function that runs in any one
50 loop. All functions in the loop will be run in sequence in the order
51 listed. The plugin system runs the functions via reference, not name,
52 so the module lists the functions by reference. The runInPkgs,
53 runInEbuild and runInFinal functions are designed in a way that allow
54 for the most flexibility and control by the module itself. As such one
55 loop level function can control the actions of the next levels. They
56 are not forced to be hard-coded. Although, there are currently no
57 modules that use or need that ability at this time.
59 Still to do in further rewites:
61 Create a file or files to store easily edited repository data
62 that can be included in the repo metadata. In that way small
63 changes can be done by maintainers without requiring a new
64 repoman release because that data comes with the release.
66 Make the plug-in checks loops configurable. Then the checks
67 run can be configured for the repo being checked. All repos
68 are not created equal and may have their own eclasses and
69 eclass checks, etc..
71 Continued code optimizations. At this point many of the scan
72 checks, etc. have not undergone extensive changes. Only what
73 was necessary to fit the new structure. Many could probably be
74 optimised for better configure-ability and execution.
75 --
76 Brian Dolbec <dolsen>