Class layout refactory

Free Ekanayaka free78@tin.it
Tue, 27 Jul 2004 11:14:15 +0200


|--==> "OS" == Otavio Salvador <otavio@debian.org> writes:

  OS> [1  <multipart/mixed (7bit)>]
  OS> [1.1  <text/plain (7bit)>]
  OS> Hello folks,

  OS> Well, I was thinking about how should we continue to implement the
  OS> code and stoped to think again in class layout.

  OS> Currently we have some direct problems with the classes:

  OS>  SourcePackage (subclass of Package)
  OS>  PackageSource (class to build the PackageList)

  OS> Someone have a better name to PackageSource?

  OS> The names is not good. I think we should change it.

  OS> Well, let us think some about PackageSource classes. They will build a
  OS> PackageList and, to me, a more logical way to do it is provide a
  OS> Backend like parameter so this can access all needed information to
  OS> build the remote and local package lists without problem.

  OS> We all think we should processed at this?

If we  want to have separate  classes for  binary and sources packages
I'd name them:

BinaryPackage
SourcePackage

rather then:

Package
SourcePackage

However I'm wondering whether  it would be  possible to have  only one
single class called Package that transparently handle both of them.

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

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

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

FetchLists:

   Fetches the appropriate dists/ tree:

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

   and/or

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

FilterLists:

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

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

UpdatePool:

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

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

Cheers,

Free Ekanayaka