|
krh@1
|
1 |
- keep history of installed packages/journal of package transaction,
|
|
krh@1
|
2 |
so we can roll back to yesterday, or see what got installed in the
|
|
krh@1
|
3 |
latest yum update.
|
|
krh@1
|
4 |
|
|
krh@1
|
5 |
- signed pkgs
|
|
krh@8
|
6 |
|
|
krh@8
|
7 |
- gzip repository of look-aside pkg xml files somehow?
|
|
krh@8
|
8 |
|
|
krh@8
|
9 |
- transactions, proper recovery, make sure we don't poop our package
|
|
krh@8
|
10 |
database (no more rm /var/lib/rpm/__cache*).
|
|
krh@8
|
11 |
|
|
krh@18
|
12 |
- diff from one package set to another answers: "what changed in
|
|
krh@18
|
13 |
rawhide between since yesterday?"
|
|
krh@18
|
14 |
|
|
krh@18
|
15 |
- rewrite qsort and bsearch that doesn't require global context var
|
|
krh@18
|
16 |
and can output a map describing the permutaion.
|
|
krh@18
|
17 |
|
|
krh@18
|
18 |
- use hash table for package and property lists so we only store
|
|
krh@18
|
19 |
unique lists (like for string pool).
|
|
krh@40
|
20 |
|
|
krh@40
|
21 |
- use existing, running system as repo; eg
|
|
krh@40
|
22 |
|
|
krh@40
|
23 |
razor update razor://other-box.local evince
|
|
krh@40
|
24 |
|
|
krh@40
|
25 |
to pull eg the latest evince and dependencies from another box. We
|
|
krh@40
|
26 |
should be able to regenerate a rzr pkg from the system so we can
|
|
krh@40
|
27 |
reuse the signature from the originating repo.
|
|
krh@41
|
28 |
|
|
krh@41
|
29 |
- Ok, maybe the fastest package set merge method in the end is to use
|
|
krh@41
|
30 |
the razor_importer, but use a hash table for the properties. This
|
|
krh@41
|
31 |
way we can assign them unique IDs immediately (like tokenizing
|
|
krh@41
|
32 |
strings).
|
|
krh@47
|
33 |
|
|
krh@47
|
34 |
- test suite should be easy, just keep .repo files around and test
|
|
krh@47
|
35 |
different type of upgrades that way (obsoletes, conflicts, file
|
|
krh@47
|
36 |
conflicts, file/dir problems etc). Or maybe just keep a simple file
|
|
krh@47
|
37 |
format ad use a custom importer to create the .repo files.
|
|
krh@47
|
38 |
|
|
krh@51
|
39 |
- pipelined download and install; download is network bound, install
|
|
krh@51
|
40 |
is disk bound. Start installing once we have self-contained set of
|
|
krh@51
|
41 |
packages. Install in reverse topo-sort order. Interruptible
|
|
krh@51
|
42 |
installation; stops at nearest checkpoint.
|
|
krh@52
|
43 |
|
|
krh@52
|
44 |
- make packages pointers be either an index into the package pool or a
|
|
krh@52
|
45 |
direct link to a package when there is only one package. set a high
|
|
krh@52
|
46 |
bit to indicate which it is. similar for properties.
|
|
krh@55
|
47 |
|
|
krh@55
|
48 |
- split out hash table code from importer, make the merger use just
|
|
krh@55
|
49 |
the hash table.
|
|
krh@56
|
50 |
|
|
krh@56
|
51 |
- try to clean up the
|
|
krh@56
|
52 |
|
|
krh@56
|
53 |
do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);
|
|
krh@56
|
54 |
|
|
krh@56
|
55 |
idiom for iteration of directories.
|
|
krh@63
|
56 |
|
|
krh@63
|
57 |
- version the sections in the file, put the element size in the header
|
|
krh@63
|
58 |
so we can add stuff to elements in a backwards compatible way.
|
|
krh@63
|
59 |
|
|
krh@63
|
60 |
- overlay package sets? mount a read-only /usr over nfs or from the
|
|
krh@63
|
61 |
virt-host and have a local package set overlaid over the read-only
|
|
krh@63
|
62 |
one. shouldn't need new features in the core package set data
|
|
krh@63
|
63 |
structure, but should be just conventions on top. we have the base
|
|
krh@63
|
64 |
package set from the r/o system, the overlay set from the local
|
|
krh@63
|
65 |
system and we can have an effective package set which is the merge
|
|
krh@63
|
66 |
of everything from the overlay into the base set. the effective set
|
|
krh@63
|
67 |
is easy to compute and we could do it on the fly or cache it. or
|
|
krh@63
|
68 |
maybe the effective set is the on-disk representation and the
|
|
krh@63
|
69 |
overlay can be computed when needed, we just keep a link back to the
|
|
krh@63
|
70 |
base.
|