# Current state

d-s-s provides

* "code", the check-security-support program, to check for affected
  packages on a particular system, and
* "data", the lists of packages without or with limited security support,
  together with version and explanation.

The check is triggered by a dpkg hook.

# Ideas

* Distribute "data" by other means
  * then d-s-s needs way less frequent updates
  * might be pretty easy to achieve once we agree on a distribution
    point and have a sane way to update it
* Move the "code" functionality into the package tools like apt
  * These programs can trigger the check before doing the work
  * They would do the check just once per install/upgrade/... operation,
    c-s-s is triggered several times in such a situation.
  * This might obsolete d-s-s entirely which I consider a good thing.
  * Requires coordination of all the tools' maintainers, probably too
    late for stretch.

# Distributing the "data"    

Several ways

1. "Discourages:" package relation

* Hint: Does not affect the dependency resolver
* Where to store additional information?
* Needs support in dpkg and $APT, probably not feasible for stretch
* Perhaps overkill

2. Packages index

Add the "unsupported" bit to the Packages file on ftp, in the
respective binary package's instance.

+ List is no longer part of the d-s-s package.
+ Seems pretty nifty.
- Honestly, I had no idea this was even possible.
- Again, package tools should support this.
- Requires re-creation of the Packages index in stable/oldstable when
  "the list" changes.

3. "by hand"

Distribute "the list" as a separate file ("by hand") on ftp.

+ Again, list is no longer part of the d-s-s package.
+ Less trouble on ftp compared to solution 2
- Does $APT require changes to download it?