1 We start with two razor_sets, system and upstream, and a list of
2 requested installations and removals.
4 FIXME: what about multiple upstream repos? Having to deal with
5 arbitrary numbers of razor_sets is possible, but will probably be
6 messy... It might be easier to either store all upstream repo data
7 in a single .repo file, or else merge all upstream .repo files
8 together into a single razor_set at startup. (Or some combination
11 We create a bit array of the packages in each set, indicating which
12 ones are installed; the system bitarray starts out all 1s, and the
13 upstream bitarray all 0s. Each bit is only allowed to change state
14 once during the transaction; an installed package can be removed, or
15 an uninstalled package installed, but trying to reinstall a removed
16 package, or uninstall a newly-installed package is an error. This
17 means the packages break down into four categories:
19 - installed (1 bit in the system bit array)
20 - to-be-removed (0 bit in the system bit array)
21 - to-be-installed (1 bit in the upstream bit array)
22 - installable (0 bit in the upstream bit array)
27 - Create new razor_transaction_packages ("rtp"s) for each
28 requested install or remove.
30 - while there are new rtps:
34 - Walk the system package list, upstream package list, and new
35 rtps in parallel. For each new INSTALL/FORCED_UPDATE rtp,
36 set the "new_package" field and the appropriate bit in the
37 upstream bit array. (For any not-found packages, set an
38 UNAVAILABLE error.) For each new rtp of any type (INSTALL,
39 REMOVE, FORCED_UPDATE, OBSOLETED), if there's a matching
40 system package, set the "old_package" field and clear the
41 appropriate bit in the system bit array.
43 - Walk the system and upstream property lists in parallel,
46 - For each to-be-installed non-file REQUIRES:
48 - See if there's an installed or to-be-installed
49 package that PROVIDES that property.
51 - If not, see if there's an installable package that
52 PROVIDES that property, and create a new INSTALL rtp
55 - If not, see if there's a to-be-removed package that
56 PROVIDES that property. (If we find such a package,
57 we have a CONTRADICTION error.)
59 - If none of the above, then we have an UNSATISFIABLE
62 - For each to-be-installed file REQUIRES:
64 - (We create fake file PROVIDES to match file REQUIRES
65 when importing/merging razor sets, so if there is
66 already another installed package that REQUIRES this
67 file, there will be a PROVIDES listed for it as well.)
69 - See if there's an installed package that PROVIDES
72 - If not, do a binary search of the system file tree
73 looking to see if some installed package provides
74 that file but does not have a PROVIDES for it.
76 - If not, see if there's an installable package that
77 PROVIDES that property, and create a new INSTALL rtp
80 - (If we actually work with multiple upstream
81 razor_sets, then we will need to search the upstream
82 file trees at this point, because it's possible that
83 a package in one upstream repo would require a file
84 in another upstream repo. But if we merge the
85 multiple upstream repos into a single razor_set at
86 some point, then we would not need to do that,
87 because it would be guaranteed that we would have
88 already created a fake PROVIDES if any package
91 - If no installed or installable package provides the
92 file, see if there's a to-be-removed package that
93 provides the file. (If we find such a package, we
94 have a CONTRADICTION error.)
96 - If none of the above, then we have an UNSATISFIABLE
99 - For each to-be-installed PROVIDES:
101 - Check if the new PROVIDES conflicts with an
102 installed CONFLICTS. If so, create a new
103 FORCED_UPDATE rtp for the installed package, so we
104 can try to upgrade it to a non-conflicting version.
105 (If we can't, we'll have an OLD_CONFLICT error.)
107 - Check if the new PROVIDES conflicts with an
108 installed OBSOLETES *and* the PROVIDES property
109 corresponds to the name of its package. (That is,
110 OBSOLETES are only matched against package names,
111 not arbitrary provided properties.) If so, we have
112 an ALREADY_OBSOLETE error.
114 - Check if the new PROVIDES conflicts with a
115 to-be-installed CONFLICTS. If so, we have a
118 - For each to-be-installed CONFLICTS:
120 - Basically the reverse of the previous case: check if
121 the new CONFLICTS conflicts with an installed
122 PROVIDES. If so, create a new FORCED_UPDATE rtp for
123 the installed package, so we can try to upgrade it
124 to a non-conflicting version. (If we can't, we'll
125 have an NEW_CONFLICT error.)
127 - Check if the new CONFLICTS conflicts with a
128 to-be-installed PROVIDES. If so, we have a
131 - For each to-be-installed OBSOLETES:
133 - Check if there's an installed package that PROVIDES
134 that property. If so, create an OBSOLETED rtp for
135 the installed package.
137 - If not, check if there's a to-be-installed package
138 that PROVIDES that property. If so, we have a
141 - For each to-be-removed PROVIDES:
143 - If there's also an identical to-be-installed
144 PROVIDES, we're ok and can skip this
146 - Otherwise, for each installed REQUIRES of this
149 - Look for some other installed or to-be-installed
150 property that satisfies the REQUIRES.
152 - If there isn't one, then for each installed
153 package in this REQUIRES's package list:
155 - If the PROVIDES was lost because the old
156 package was REMOVEd (not FORCED_UPDATE or
157 OBSOLETED), then create a new REMOVE rtp for
160 - Otherwise, create a new FORCED_UPDATE rtp
163 - (We don't need to look at to-be-installed REQUIRES
164 of this property, because if there are any, they
165 will cause a CONTRADICTION error when we try to
166 re-satisfy them the next time through.)