1.1 --- a/TODO	Wed Apr 09 21:28:17 2008 -0400
     1.2 +++ b/TODO	Mon Jun 09 16:14:05 2008 -0400
     1.3 @@ -1,5 +1,12 @@
     1.4  Towards replacing rpm + yum (0.1):
     1.5  
     1.6 +- drop the filelists from the main package set file, split out to a
     1.7 +  secondary file.  for package sets that depend on other package sets,
     1.8 +  we need to be able to generate properties with owning packages that
     1.9 +  are in another set.  this way, a package that requires a file, will
    1.10 +  look up the provides in the set and find the package that owns it
    1.11 +  and then try mark that for update.
    1.12 +
    1.13  - installer part:
    1.14  
    1.15     - pre install check; check that dirs can be created (no files where
    1.16 @@ -8,6 +15,10 @@
    1.17  
    1.18     - store rpm headers for installed packages.
    1.19  
    1.20 +   - implement rpm uninstall and update.
    1.21 +
    1.22 +   - triggers? just say no?
    1.23 +
    1.24  - rpm seems to consider glibc > 2.6.90 to mean greater than
    1.25    2.6.90-anything.  That is, a comparison that doesn't mention the
    1.26    release field, shouldn't regard the release field of pkgs it
    1.27 @@ -25,8 +36,6 @@
    1.28  
    1.29  - signed packages
    1.30  
    1.31 -- figure out how to canonically represent empty string... ~0?
    1.32 -
    1.33  - space calculation before transaction, but ideally, do a number of
    1.34    smaller transactions.
    1.35  
    1.36 @@ -45,6 +54,67 @@
    1.37    (system.repo.lock or so, see git) so that razor updates are
    1.38    prevented if the systems crashes during an update.
    1.39  
    1.40 +- implement depsolving between multiple package sets by creating an
    1.41 +  iterator that has a sorted list of all installed pkgs from all sets,
    1.42 +  all installed requires from all sets, all installed provides from
    1.43 +  all sets etc.  could be a list of tuples (pkgs index, set index).
    1.44 +  should simplify even the two-set depsolving a bit since we can
    1.45 +  pretend there's just one set.  this should also be useful for the
    1.46 +  'overlay set' idea where the system set is actually made up of a
    1.47 +  number of sets, but typically a read-only set from a read-only fs
    1.48 +  and a read-write set from a r/w fs.
    1.49 +
    1.50 +- locking: we use advisory file locking on the system set
    1.51 +  (/var/lib/razor/system.repo) to indicate a transaction is in
    1.52 +  progress.  The locking algorithm is as follows:
    1.53 +
    1.54 +    1. obtain advisory lock on system set.  if this is already taken,
    1.55 +       we know that a process is actively modifying the system set and
    1.56 +       we have to wait.  there's a fcntl that lets you block for the
    1.57 +       lock to go away.
    1.58 +
    1.59 +    2. if a system-next.repo file already exists an earlier razor
    1.60 +       process was interrupted or crashed and we may want to clean
    1.61 +       that up.  the system-next.repo file will record what the
    1.62 +       previous instance was trying to do and we can just replay that
    1.63 +       to clean up.
    1.64 +
    1.65 +    3. create the new package set whichever way and write it to
    1.66 +       system-next.repo, then start installing/removing rpms.
    1.67 +
    1.68 +    4. When the update is complete, rename system-next.repo to
    1.69 +       system.repo and remove the advisory lock.
    1.70 +
    1.71 +  we should probably introduce a new object that encapsulates this
    1.72 +  sequence, the filename conventions, rpm cache, e.g. struct
    1.73 +  razor_image, with operations such as
    1.74 +
    1.75 +	#define RAZOR_IMAGE_READ	0x01
    1.76 +	#define RAZOR_IMAGE_WRITE	0x02
    1.77 +
    1.78 +	struct razor_image *
    1.79 +	razor_image_open(const char *root, unsigned int flags);
    1.80 +
    1.81 +	int
    1.82 +	razor_image_begin_transaction(struct razor_image *image,
    1.83 +				      struct razor_set *target);
    1.84 +
    1.85 +	int
    1.86 +	razor_image_finish_transaction(struct razor_image *image);
    1.87 +
    1.88 +  the transaction pipelineing described above sits on top of this,
    1.89 +  since each step there needs to complete a full transaction that
    1.90 +  writes out a new package set.
    1.91 +
    1.92 +  for overlay package sets we could do something like
    1.93 +
    1.94 +	struct razor_image *
    1.95 +	razor_image_open_with_base(const char *root, unsigned int flags,
    1.96 +				   struct razor_image *base);
    1.97 +
    1.98 +  where base specifies the r/o package set it's layered on.  this
    1.99 +  allows for stacking several layers of images.
   1.100 +
   1.101  
   1.102  Package set file format items:
   1.103