[debpool] Re: Refactoring the main loop

[Free Ekanayaka]

|--==> Magnus Holmgren writes:

  MH> I have identified four or five sections of the foreach $changefile loop that 
  MH> can be broken out into one subroutine each to make the code more 
  MH> understandable:

  MH> 1. Check_Files(): Parse the .changes file; check that all the files it lists 
  MH> are there and have the correct MD5 checksum; check that the list of files is 
  MH> consistent with the Source, Binary, and Architecture fields, and that there 
  MH> are no unrecognized files. Parse the .dsc file if source is uploaded; check 
  MH> that all files listed have the same properties as in the .changes file and/or 
  MH> (for a .orig.tar.gz) as the existing file in the archive, that the file names 
  MH> are consistent with the Version field and Source fields, and that there are 
  MH> no unrecognized files. While we're at it, why not perform similar checks on 
  MH> the debs too? Hmm, if we're going to perform such extensive checking I guess 
  MH> it could be broken down further.

Do you mean if the .debs are consistent with the .dsc list?

  MH> 2. Check_Versions() (skipped when --rollback is used): Check that all files 
  MH> are newer than the ones in the target distribution, and that they pass 
  MH> additional checks as discussed in the other thread.

This function should be probably modified to support multi-arch
packages. The comparison should happen between packages belonging to
the same arch.

  MH> 3. Do_Install(): Install the packages in the archive and remove versions that 
  MH> are no longer referenced (maybe this doesn't have to be a separate sub).

Maybe we could have an option to tell debpool to store the old
packages in some directory instead of deleting them completely.

  MH> 4-5. Do_Generate_Dist_Info(): Rebuild the Packages, Sources, and Release files 
  MH> as well as the optional compressed versions and gpg signatures. I'm thinking 
  MH> that this should be done in two steps per dist: first all files are generated 
  MH> and their names and destinations are put in a list; then all files are 
  MH> installed in the archive. This should minimize the chance that the archive 
  MH> ends up in an inconsistent state. Actually, it's better if old packages are 
  MH> cleaned out last instead of in step 3.

That's a very good idea.

Ciao,

Free