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