1 Towards replacing rpm + yum (0.1):
5 - pre install check; check that dirs can be created (no files where
6 want to create dirs), move config files according to file
9 - store rpm headers for installed packages.
11 - rpm seems to consider glibc > 2.6.90 to mean greater than
12 2.6.90-anything. That is, a comparison that doesn't mention the
13 release field, shouldn't regard the release field of pkgs it
14 compares against. glibc-common-2.6.90 has
16 conflicts: glibc < 2.6.90, glibc > 2.6.90
18 since rpm doesn't let you do glibc != 2.6.90, and
20 requires: glibc = 2.6.90
22 will always pull in glibc. But even with a != relation, would
23 glibc-2.6.90-16 be equal to 2.6.90? glibc 2.7.90-8 dropped it in
24 favor of requires = 2.7.90-8 (#225806).
28 - figure out how to canonically represent empty string... ~0?
30 - space calculation before transaction, but ideally, do a number of
33 - pre-link changing binaries and libs on disk screwing up checksum?
35 - pipelined download and install; topo-sort packages in update set,
36 pick one with all deps in the current set, add it to the current set
37 and satisfy deps against update set => result: minimal update
38 transaction. Queue download and install/update transaction for the
39 packages in the minimal set, start over. This also makes the
40 installation phase much more interruptible, basically just stop
41 after a sub-transaction finishes. As we keep the update set around
42 as a target, we can restart if needed. Probably don't need to, can
43 just do a new update. During a sub-transaction we should keep the
44 target set (i.e. the current set to be) around as a lock file
45 (system.repo.lock or so, see git) so that razor updates are
46 prevented if the systems crashes during an update.
49 Package set file format items:
51 - drop the 4k section alignment
53 - just use strings for header identifiers, make the string pool
54 section have a fixed string (maybe make "strings" always the first
55 string so its index is 0), or maybe just require that it's the first
58 - nail down byte-order of repo file.
60 - version the sections in the file, put the element size in the header
61 so we can add stuff to elements in a backwards compatible way.
62 maybe not necessary, we can just add sections that augment the
63 sections we want to add to (similar to how rpm has add versioned
69 - keep history of installed packages/journal of package transaction,
70 so we can roll back to yesterday, or see what got installed in the
73 - transactions, proper recovery, make sure we don't poop our package
74 database (no more rm /var/lib/rpm/__cache*).
76 - use hash table for package and property lists so we only store
77 unique lists (like for string pool).
79 - use existing, running system as repo; eg
81 razor update razor://other-box.local evince
83 to pull eg the latest evince and dependencies from another box. We
84 should be able to regenerate a rzr pkg from the system so we can
85 reuse the signature from the originating repo.
87 - Ok, maybe the fastest package set merge method in the end is to use
88 the razor_importer, but use a hash table for the properties. This
89 way we can assign them unique IDs immediately (like tokenizing
92 - test suite should be easy, just keep .repo files around and test
93 different type of upgrades that way (obsoletes, conflicts, file
94 conflicts, file/dir problems etc). Or maybe just keep a simple file
95 format ad use a custom importer to create the .repo files.
99 do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);
101 idiom for iteration of directories.
103 - overlay package sets? mount a read-only /usr over nfs or from the
104 virt-host and have a local package set overlaid over the read-only
105 one. shouldn't need new features in the core package set data
106 structure, but should be just conventions on top. we have the base
107 package set from the r/o system, the overlay set from the local
108 system and we can have an effective package set which is the merge
109 of everything from the overlay into the base set. the effective set
110 is easy to compute and we could do it on the fly or cache it. or
111 maybe the effective set is the on-disk representation and the
112 overlay can be computed when needed, we just keep a link back to the
115 - incremental rawhide repo updates? instead of downloading 10MB zipped
116 repo every time, download a diff repo? Should be pretty small,
117 especially if we don't have file checksums in metadata. Filenames
118 and properties are for the most part already present, typically just
119 a version bump plus maybe tweaking a couple requires. The upstream
120 repo can store multiple incremental updates in one big file and
121 provide an index file that maps updates for a given date (we should
122 use repo-file checksums though) to a range in the file: Download the
123 index file, search for a match for your latest rawhide.repo file,
124 download range of updates that brings it up to date.
126 - use hash tables for dirs when importing files to avoid qsorting all
131 - eliminate duplicate entries in package property lists.