Class layout refactory

[Free Ekanayaka]

|--==> "FE" == Free Ekanayaka <free78@tin.it> writes:

  FE> About the PackageSource   class  issue I'm  wondering  whether  if you
  FE> really need such a class.

  FE> Basically a RemoteBackend is defined specifying server, architectures,
  FE> distributions, components  and filters/includes/excludes.

  FE> So I'd simply write some methods for the RemoteBackend class:

  FE> FetchLists:

  FE>    Fetches the appropriate dists/ tree:

  FE>    dists/[distributions]/[components]/binary-[architectures]/Packages.gz

  FE>    and/or

  FE>    dists/[distributions]/[components]/sources/Sources.gz

  FE> FilterLists:

  FE>    Filters the list   files that have  been fetched  (Packages.gz or
  FE>    Sources.gz), building  a PackageList object for  each  of them.

  FE>    This is done by  applying the filter/exclude/include rules  defined
  FE>    in  the configuration file for   this backend, and then calculating
  FE>    the closure of dependencies.

  FE> UpdatePool:

  FE>    Updates  the pool/ directory  according to the PackageLists objects
  FE>    built by the  FilterLists method,  possibly  fetching new files  or
  FE>    deleting unwanted ones.

  FE> Of course for a MergeBackend object we need a different schema.

While thinking on how to  enhance the resolv_dep_using option (more on
this below), I changed a little bit my mind.

Here's a slightly   modified  class layout with  some   implementation
comments.

######################################################################

BinaryPackage - store information about a binary package

SourcePackage - store the extra information needed to deal with source 
                packages using a list of dictionaries

[maybe these two classes can be merged]

######################################################################

PackageList - just what it sounds like, a listing of packages from a
              single source

Functionality: provide a list of packages and where to get them from; 
tell what packages depend on other packages; perform filtering on the 
list and provide a subset of packages

######################################################################

AptSource - where to get packages (this class somewhat replaces the 
            former RemoteBackend)

Functionality: provides a kind of sources.list entry;  the set of all
AptSource objects defines all the available packages.

Configuration file example (with alternate format):

AptSources
{
   Debian
   {
      Location "http://ftp.debian.it/debian";
      Distributions
      {
         sarge;
         sid;
      }
      Components
      {
         main;
         contrib;
         non-free;
         main/debian-installer;
      };
   };
   MyPackages
   {
      Location "file:///var/lib/custom-packages";
      Distributions
      {
         experimental;
      }
      Components
      {
         local;
      }
   };
};

Implementation: after parsing the configuration file an each AptSource
object is initialised fetching the Packages.gz/Sources.gz files, and
caching them in, say, /var/cache/debpartial-mirror/<AptSource>/dists/.

######################################################################

CustomDist - a custom selection of package (this class somewhat 
             replaces the former MergeBackend)

Functionalities: merge AptSource object together, by filtering/selecting
packages and resolving dependences.

Configuration file (with alternate format):

//
// List of custom distributions, built mixing and filtering the APT sources.
//
CustomDist
{
   MyDistro
   {
      //
      // This entry pulls in the base system from sarge
      //
      SargeBase
      {
         AptSources
         {
            Debian::sarge::main;
         };
         Filters
         {
            Section
            {
               base;
            };
            Priority
            {
               required;
               important;
            };
         };
      };
      //
      // This entry pulls in all the packages in section sound plus 
      // some other interesting ones.
      //
      // The packages are grabbed from my packages and sid , in this order,
      // i.e. if package A is present both in my packages and sid, the one
      // in my packages has the precendence.
      //
      // Dependences are resolved giving precendence to the packages from
      // my packages, sarge and sid, in this order.
      //
      MixedSoundPackages
      {
         AptSources
         {
            MyPackages;
            Debian::sid;
         };
         ResolveDepsUsing 
         {
            MyPackages;
            Debian::sarge;
            Debian::sid;
         };
         Filters
         {
            Section
            {
               sound;
            };
         };
         Include "/mytasks/some_sound_related_packages"
      };
   };        
};

Implementation: builds PackageList objects from the files fetched by 
AptSources, then it processes it according to the rules defined in
the Filters, Include and ResolveDepsUsing.

Note that for   sake  of simplicity   I've temporary   left  aside the
architecture options, but it should not be hard to figure out which is
the best way to handle them in this schema.

Cheers,

Free Ekanayaka