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