deal with a single package being the target of both a FORCED_UPDATE and an INSTALL
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. These will be "unresolved", because
29 we haven't yet found the razor_packages that correspond to them.
31 - while there are new rtps:
35 - Walk the system property list, upstream property list, and
36 new rtp list in parallel, and:
38 - For each uninstalled PROVIDES:
40 - If the property is a valid package name (that is,
41 either it's a package providing its own name, or it
42 has a matching OBSOLETES), and it matches the name
43 of a new rtp of type INSTALL or FORCED_UPDATE with
44 an unresolved new_package, then set the rtp's
45 new_package to point to the package providing this
46 property and set the appropriate bit in the upstream
49 - For each to-be-installed non-file REQUIRES:
51 - See if there's an installed or to-be-installed
52 package that PROVIDES that property.
54 - If not, see if there's an installable package that
55 PROVIDES that property, and create a new INSTALL rtp
58 - If not, see if there's a to-be-removed package that
59 PROVIDES that property. (If we find such a package,
60 we have a CONTRADICTION error.)
62 - If none of the above, then we have an UNSATISFIABLE
65 - For each to-be-installed file REQUIRES:
67 - (We create fake file PROVIDES to match file REQUIRES
68 when importing/merging razor sets, so if there is
69 already another installed package that REQUIRES this
70 file, there will be a PROVIDES listed for it as well.)
72 - See if there's an installed package that PROVIDES
75 - If not, do a binary search of the system file tree
76 looking to see if some installed package provides
77 that file but does not have a PROVIDES for it.
79 - If not, see if there's an installable package that
80 PROVIDES that property, and create a new INSTALL rtp
83 - (If we actually work with multiple upstream
84 razor_sets, then we will need to search the upstream
85 file trees at this point, because it's possible that
86 a package in one upstream repo would require a file
87 in another upstream repo. But if we merge the
88 multiple upstream repos into a single razor_set at
89 some point, then we would not need to do that,
90 because it would be guaranteed that we would have
91 already created a fake PROVIDES if any package
94 - If no installed or installable package provides the
95 file, see if there's a to-be-removed package that
96 provides the file. (If we find such a package, we
97 have a CONTRADICTION error.)
99 - If none of the above, then we have an UNSATISFIABLE
102 - For each to-be-installed PROVIDES:
104 - Check if the new PROVIDES conflicts with an
105 installed CONFLICTS. If so, create a new
106 FORCED_UPDATE rtp for the installed package, so we
107 can try to upgrade it to a non-conflicting version.
108 (If we can't, we'll have an OLD_CONFLICT error.)
110 - Check if the new PROVIDES conflicts with an
111 installed OBSOLETES *and* the PROVIDES property
112 corresponds to the name of its package. (That is,
113 OBSOLETES are only matched against package names,
114 not arbitrary provided properties.) If so, we have
115 an ALREADY_OBSOLETE error.
117 - Check if the new PROVIDES conflicts with a
118 to-be-installed CONFLICTS. If so, we have a
121 - For each to-be-installed CONFLICTS:
123 - Basically the reverse of the previous case: check if
124 the new CONFLICTS conflicts with an installed
125 PROVIDES. If so, create a new FORCED_UPDATE rtp for
126 the installed package, so we can try to upgrade it
127 to a non-conflicting version. (If we can't, we'll
128 have an NEW_CONFLICT error.)
130 - Check if the new CONFLICTS conflicts with a
131 to-be-installed PROVIDES. If so, we have a
134 - For each to-be-installed OBSOLETES:
136 - Check if there's an installed package that PROVIDES
137 that property. If so, create an OBSOLETED rtp for
138 the installed package.
140 - If not, check if there's a to-be-installed package
141 that PROVIDES that property. If so, we have a
145 - For each installed PROVIDES:
147 - If the property is a valid package name (that is,
148 it's a package providing its own name), and it
149 matches the name of a new rtp with an unresolved
150 old_package, then set the rtp's old_package to point
151 to the package providing this property and clear the
152 appropriate bit in the system bit array.
154 - For each to-be-removed PROVIDES:
156 - If there's also an identical to-be-installed
157 PROVIDES, we're ok and can skip this
159 - Otherwise, for each installed REQUIRES of this
162 - Look for some other installed or to-be-installed
163 property that satisfies the REQUIRES.
165 - If there isn't one, then for each installed
166 package in this REQUIRES's package list:
168 - If the PROVIDES was lost because the old
169 package was REMOVEd (not FORCED_UPDATE or
170 OBSOLETED), then create a new REMOVE rtp for
173 - Otherwise, create a new FORCED_UPDATE rtp
176 - (We don't need to look at to-be-installed REQUIRES
177 of this property, because if there are any, they
178 will cause a CONTRADICTION error when we try to
179 re-satisfy them the next time through.)