[Aptitude-devel] aptitude: add "New Origin Browser" to the view menu

[Daniel Hartwig]

On 12 Nov 2010, Jens Getreu <getreu at web.de> wrote:
> [...]
> 1. I sometime try out packages from a repository I include
>    temporary. Then f. ex. I find out that these packages installed are
>    not stable enough and I want to get rid of them.
>
>    It would be good if there where a "new Origine Browser" view like
>    in synaptic, where you can browse package according to there
>    origin.

What does this look like in Synaptic?

Synaptic does not support folder nesting and so presents an origin
view with groups labelled "archive/section (origin)":
  All
  Local
  experimental/iceweasel-beta (mozilla.debian.net)
  unstable/main (ftp.au.debian.org)
  unstable/main (mozilla.debian.net)

aptitude can do better than this simple flat view.  Here are
some, obvious, ideas:

a) policy "archive,site,section(topdir)"
   --\ experimental (4)
     --\ mozilla.debian.net (4)
       --- main
   --\ unstable (32900)
     --\ Local (12)
       --- main
     --- ftp.au.debian.org (32883)
     --- mozilla.debian.net (5)

b) policy "site,archive,section(topdir)"
   --- Local (12)
   --\ ftp.au.debian.org (34395)
     --\ unstable (32883)
       --- main
   --\ mozilla.debian.net (9)
     --\ experimental (4)
       --- iceweasel-beta (4)
     --- unstable (5)

I do not use "status" here, as the current debtags and categorical
browsers do not use it either.

There is neither "site" nor "archive" grouping policy currently in
aptitude.  The patch just submitted against #298734 adds support for
by-site, so I am blocking on it.

"archive" can be approximated as "pattern(?archive())", however,
packages will only be listed under a single archive, even if they
occur in more than one (only the first matching version is used to
determine where it a package gets placed--this is documented
behaviour).

Synaptic also suffers from this problem, atleast in squeeze.

There is the additional problem that a package can be place under an
incorrect archive for the given site.  This is because all available
package versions will be tested for each site, regardless of whether
those versions are available at that particular site.[1]

---[Example]
sources.list:
# Provides 3 distinct versions of iceweasel.
deb http://ftp.au.debian.org/debian sid main
deb http://ftp.au.debian.org/debian squeeze main
deb http://mozilla.debian.net/ experimental iceweasel-beta

origin browser a) with limit "^iceweasel$":
--\ unstable (2)
  --\ ftp.au.debian.org (1)
    --\ main
      iceweasel
  --\ mozilla.debian.net (1)
    --\ main
      iceweasel

should be:
--\ experimental (1)
  --\ mozilla.debian.net (1)
    --\ iceweasel-beta
      iceweasel
--\ stable (1)
  --\ ftp.au.debian.org (1)
    --\ main
      iceweasel
--\ unstable (1)
  --\ ftp.au.debian.org (1)
    --\ main
      iceweasel
---

It is good that this view can be somewhat approximated right now, however
it would be even better to be able to implement it correctly.

To this end I will file wishlist for "archive" grouping policy and
investigate ways of correctly filtering VersionList in subtrees.


---
[1] Technically:
      1. On add_package(), PkgIterator::VersionList() is scanned for a
         match.
      2. PkgIterator is passed unmodified to matching subtree.
      3. Subtree processes PkgIterator as though all versions in the
         original still apply.

    Modifying PkgIterator in step 2. is what we want to do, this can
    be done by passing a proxy whose ::VersionList() returns a
    filtered VerIterator.  If a pkg is passed to the subtree for
    `mozilla.debian.net', then VersionList() should only iterate
    over versions available on that site.

    Of course, I have not yet thoroughly investigated the internal
    workings of the package tree to determine whether passing around
    such filtered packages is a good idea.