Todo List

Group acquire

Acquire supports inserting an object into several queues at once, but it is not clear what its behavior in this case is, and no subclass of pkgAcquire::Item seems to actually use this capability.

Class pkgAcqIndex

Why does pkgAcqIndex have protected members?

Member pkgAcqIndexDiffs::available_patches

These are indexed by sha1sum; why not use some sort of dictionary instead of relying on ordering and stripping them off the front?

Class pkgAcqMetaSig

Why protected members?

Member pkgAcqMetaSig::IndexTargets

Why a list of pointers instead of a list of structs?

Class pkgAcquire

Why all the protected data items and methods?

Member pkgAcquire::Configs

why a hand-managed config dictionary instead of std::map?

Member pkgAcquire::Item::ID

it's unused in apt itself

Member pkgAcquire::MethodConfig::Next

Why not an STL container?

Class pkgAcquire::Queue

Why so many protected values?

Member pkgAcquire::Queue::Bump ()

Why both this and Cycle()? Are they expected to be different someday?

Member pkgAcquire::Queue::Items

why a by-hand list instead of an STL structure?

Member pkgAcquire::Queue::ItemStart (QItem *Itm, unsigned long long Size)

Unimplemented. Implement it or remove?

Member pkgAcquire::Queue::Workers

This is plural because support exists in Queue for multiple workers. However, it does not appear that there is any way to actually associate more than one worker with a queue.

Why not just use a std::set?

Member pkgAcquire::Queues

why a hand-managed list of queues instead of std::list or std::set?

Class pkgAcquire::Worker

Like everything else in the Acquire system, this has way too many protected items.

Member pkgAcquire::Worker::Access

Doesn't this duplicate Config->Access?

Member pkgAcquire::Worker::InReady

Is this right? It's a guess.

Member pkgAcquire::Worker::NextQueue

This is always NULL; is it just for future use?

Member pkgAcquire::Worker::OutQueue

Wouldn't a std::dequeue be more appropriate?

Member pkgAcquire::Worker::OutReady

Is this right?

Member pkgAcquire::Worker::RunMessages ()

Several message types lack separate handlers.

Member pkgAcquire::Workers

why a hand-managed list of workers instead of std::list or std::set?

Class pkgAcquireStatus

Why protected members?

Member pkgAcquireStatus::MediaChange (std::string Media, std::string Drive)=0

This is a horrible blocking monster; it should be CPSed with prejudice.

Member pkgDepCache::GetRootSetFunc ()

Is this the best place for this function? Perhaps the settings for mark-and-sweep should be stored in a single external class?