Steps to reproduce:

- Have an apt source for
  "deb http://repo.steampowered.com/steam/ precise steam"
  (plus some way to mark it as trusted)
- Observe how the steam-launcher package offered by that repository is
  presented in the TUI
  (It has Section: games, is in a component/archive area named steam,
  and comes from Origin: Valve Software LLC, Label: Steam)

(Any other archive with similar structure can probably reproduce this,
that's just the first one I thought of)

Expected result:

- The package is presented as though it was in no particular archive
  component, because aptitude presumably doesn't know what policies the
  origin "Valve Software LLC" uses when marking packages with a Section
  and putting them in a component

Actual result:

Hi Simon,

Simon McVittie wrote:

The string "The main Debian archive" is a static description string
for archives called "main" and does not handle any kind of "origin".
See
https://anonscm.debian.org/cgit/aptitude/aptitude.git/tree/section-descriptions#n83
for the place where the string comes from.

I can't tell you since when this is the case as this static string
hasn't changed since at least 2005 when the contents from old
Subversion repository has been imported (without history) into
Mercurial.

So this generally happens if some other repo also contains an archive
named "main" or if there is no archive name given[1].

[1] Couldn't find the actual code for that, but it's the case
    according to the comment at
https://anonscm.debian.org/cgit/aptitude/aptitude.git/tree/src/pkg_grouppolicy.h#n129

So yes, this should be fixed as it's indeed wrong and confusing.

But it's the case like this since ages (at least nearly two decades)
and nobody bothered(*) until now. Hence downgrading the severity to
"minor". (Feel free to raise the severity again if you disagree with
my reasoning.)

And it's probably neither clear how to fix it (What logic should be
implemented given those static descriptions? Do we need a "main"
description for Debian and for Non-Debian?) nor if it will be trivial
to fix as the current method is dead simple.

(*) I'm actually aware of that shortcoming for years now, but it never
    bothered me enough that I even thought about documenting it in a
    bug report.

		Regards, Axel

I assume you mean archive areas (which is what Policy calls the conceptual
division between main, contrib and non-free) or components (which is what
apt calls the data layout that implements that conceptual division).

The component containing steam-launcher is called steam, and its Section
is games, so it can't be coming from an explicit mention of main.
Presumably aptitude is applying this pseudocode:

    if '/' in Section:
        archive-area, section = Section.split('/')
    else:
        archive-area = 'main'
        section = Section

Debian Policy §2.4 does talk about how the Section field should reflect
the archive area, but non-Debian archives aren't bound by Policy.
In practice, I think third-party .deb distributors like Valve and GOG
will probably choose an unadorned Section like 'games' more often than
they choose one that encodes an archive area like 'non-free/games',
even if arguably they should be using 'non-free/games' or 'steam/games'
or similar.

I can see that the information available to aptitude doesn't make this
at all easy, because it can know which apt origin an available package
comes from (it's in the Release file), but cannot in general know which
origin an already-installed package came from (all it knows is the dpkg
metadata, which doesn't include the origin); so it can't know whether
the absence of an archive area prefix in the Section means Debian main,
or Ubuntu main, or some third-party thing that isn't necessarily even
Free Software.

    smcv