--- /tmp/apt-2.3.12bozn3cwn/debian/libapt-pkg-doc_2.3.12_all.deb +++ libapt-pkg-doc_2.3.12_all.deb ├── file list │ @@ -1,3 +1,3 @@ │ -rw-r--r-- 0 0 0 4 2021-11-17 17:26:57.000000 debian-binary │ -rw-r--r-- 0 0 0 30932 2021-11-17 17:26:57.000000 control.tar.xz │ --rw-r--r-- 0 0 0 947120 2021-11-17 17:26:57.000000 data.tar.xz │ +-rw-r--r-- 0 0 0 947096 2021-11-17 17:26:57.000000 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ ├── data.tar.xz │ ├── data.tar │ │ ├── ./usr/share/doc/libapt-pkg-doc/html/todo.xhtml │ │ │ @@ -43,47 +43,51 @@ │ │ │
│ │ │
Todo List
│ │ │ │ │ │
│ │ │
│ │ │
Module 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.
│ │ │ +
Member MMap::Map (FileFd &Fd)
│ │ │ +
Writing to compressed fd's ?
│ │ │ +
Class pkgAcqIndex
│ │ │ +
Why does pkgAcqIndex have protected members?
│ │ │ +
Class pkgAcqMetaSig
│ │ │ +
Why protected members?
│ │ │ +
Class pkgAcquire
│ │ │ +

Why so many protected values?

│ │ │ +

Why all the protected data items and methods?

│ │ │ +

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

│ │ │ +
│ │ │ +
Member pkgCdrom::Add (pkgCdromStatus *log)
│ │ │ +
We ignore stat() errors here as we usually have only one of those in use
│ │ │ +
Member pkgDPkgPM::Go (APT::Progress::PackageManager *progress) APT_OVERRIDE
│ │ │ +
workaround for dpkg bug, see our ./test-bug-740843-versioned-up-down-breaks test
│ │ │
Member CacheSetHelper::PackageFromString (PackageContainerInterface *const pci, pkgCacheFile &Cache, std::string const &pattern)
│ │ │
hm, hm, regexp/fnmatch incompatible?
│ │ │
Member CommandLine::GetCommand (Dispatch const *const Map, unsigned int const argc, char const *const *const argv) APT_PURE
│ │ │
How like is it that an option parameter will be also a valid Match ?
│ │ │
Member debReleaseIndex::Load (std::string const &Filename, std::string *const ErrorText) APT_OVERRIDE
│ │ │
find better tag name
│ │ │
Member edspListParser::ParseStatus (pkgCache::PkgIterator &Pkg, pkgCache::VerIterator &Ver) APT_OVERRIDE
│ │ │
Using an overriding pin is wrong.
│ │ │ -
Member MMap::Map (FileFd &Fd)
│ │ │ -
Writing to compressed fd's ?
│ │ │
Member PackageManagerFancy::GetTerminalSize ()
│ │ │
get from "child_pty" instead?
│ │ │
Member PackageManagerProgressDeb822Fd::StartDpkg () APT_OVERRIDE
│ │ │
use SetCloseExec here once it taught about throwing
│ │ │
Member PackageManagerProgressFd::StartDpkg () APT_OVERRIDE
│ │ │
use SetCloseExec here once it taught about throwing
│ │ │
Member pkgAcqDiffIndex::ParseDiffIndex (std::string const &IndexDiffFile)
│ │ │
all of pdiff supports only .gz compressed patches
│ │ │
Member pkgAcqDiffIndex::pkgAcqDiffIndex (pkgAcquire *const Owner, pkgAcqMetaClearSig *const TransactionManager, IndexTarget const &Target) APT_NONNULL(2
│ │ │
Magic number as an upper bound on pdiffs we will reasonably acquire
│ │ │ -
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::Failed (std::string const &Message, pkgAcquire::MethodConfig const *const Cnf) APT_OVERRIDE
│ │ │
this is used often (e.g. in pkgAcqIndexTrans) so refactor
│ │ │ -
Class pkgAcquire
│ │ │ -

Why all the protected data items and methods?

│ │ │ -

Why so many protected values?

│ │ │ -

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

│ │ │ -
│ │ │
Member pkgAcquire::Access
│ │ │
Doesn't this duplicate Config->Access?
│ │ │
Member pkgAcquire::Bump ()
│ │ │
Why both this and Cycle()? Are they expected to be different someday?
│ │ │
Member pkgAcquire::Configs
│ │ │
why a hand-managed config dictionary instead of std::map?
│ │ │
Member pkgAcquire::InReady
│ │ │ @@ -100,18 +104,18 @@ │ │ │
Wouldn't a std::dequeue be more appropriate?
│ │ │
Member pkgAcquire::OutReady
│ │ │
Is this right?
│ │ │
Member pkgAcquire::Queues
│ │ │
why a hand-managed list of queues instead of std::list or std::set?
│ │ │
Member pkgAcquire::RunMessages ()
│ │ │
Several message types lack separate handlers.
│ │ │ -
Member pkgAcquire::Workers
│ │ │ -

Why not just use a std::set?

│ │ │ -

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

│ │ │ -

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.

│ │ │ +
Member pkgAcquire::Workers
│ │ │ +

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

│ │ │ +

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?

│ │ │
│ │ │
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 pkgCache< Str, Itr >::DescFile::Size
│ │ │
document pkgCache::DescFile::Size
│ │ │ @@ -123,31 +127,27 @@ │ │ │
enumerate at least the possible indexes
│ │ │
Member pkgCache< Str, Itr >::ReleaseFile::Flags
│ │ │
document PackageFile::Flags
│ │ │
Member pkgCache< Str, Itr >::VerFile::Size
│ │ │
document pkgCache::VerFile::Size
│ │ │
Member pkgCacheGenerator::MakeStatusCache (pkgSourceList &List, OpProgress *Progress, MMap **OutMap, pkgCache **OutCache, bool AllowMem=false)
│ │ │
deprecate the ignored AllowMem parameter
│ │ │ -
Member pkgCdrom::Add (pkgCdromStatus *log)
│ │ │ -
We ignore stat() errors here as we usually have only one of those in use
│ │ │
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?
│ │ │
Member pkgDepCache::Policy::IsImportantDep (DepIterator const &Dep) const
│ │ │
this is a meant as a temporary solution until the
│ │ │ -
Member pkgDPkgPM::Go (APT::Progress::PackageManager *progress) APT_OVERRIDE
│ │ │ -
workaround for dpkg bug, see our ./test-bug-740843-versioned-up-down-breaks test
│ │ │
Member pkgDPkgPM::OpenLog ()
│ │ │
use a better string after freeze
│ │ │
Member pkgDPkgPM::ProcessDpkgStatusLine (char *line)
│ │ │ -

2: is "pkgname" here reliable with dpkg only sending us

│ │ │ -

this needs a muliarch testcase

│ │ │ +

this needs a muliarch testcase

│ │ │ +

2: is "pkgname" here reliable with dpkg only sending us

│ │ │
│ │ │
Member pkgPackageManager::EarlyRemove (PkgIterator Pkg, DepIterator const *const Dep) APT_MUSTCHECK
│ │ │ -

Unify messaging with Protected below.

│ │ │ -

Message should talk about Protected, not Essential, and unified.

│ │ │ +

Message should talk about Protected, not Essential, and unified.

│ │ │ +

Unify messaging with Protected below.

│ │ │
│ │ │
Member pkgPolicy::pkgPolicy (pkgCache *Owner)
│ │ │
make ExpressionMatches static to use it here easily
│ │ │
Member pkgProblemResolver::ResolveInternal (bool const BrokenFix=false)
│ │ │

we should undo the complete MarkInstall process here

│ │ │

use DoUpgrade(Pkg) instead?

│ │ │