summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/additional_software_packages.mdwn
blob: cdddb410c18778703b3134c9d3eea3083641d734 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
[[!meta title="User interface for additional software packages"]]

The persistence feature for additional software packages is a great tool
to make Tails more flexible for diverse scenarios without having to
bloat the ISO image.

The current limitations include:

  - No user interface. Currently you have to edit a file as root. ([[!tails_ticket 5996 desc="#5996"]])

  - Their Installation locks the opening of the desktop. ([[!tails_ticket 9059 desc="#9059"]])

  - They are checked for updates every time Tor is restated. ([[!tails_ticket 9819 desc="#9819"]])

Proposed user experience
========================

1. When installing a new package, either through the command line or
through Synaptic, the user is asked whether she wants to make it
persistent.

2. When removing a persistent package, the user is asked whether she
wants to remove it from the list of persistent packages.

3. Have a list of the persistent packages visible in the persistence
wizard. As the user need to be able to check the state of this feature
outside of APT operations.

4. Allow removing packages from the list in 3 (optional).

5. Allow adding packages to the list in 3 (optional).

Implementation
--------------

  - 1 and 2 might be possible to implement using APT hooks. We need to
    investigate how these APT hooks would communicate with the desktop
    notifications.

  - 3 might require modifying the general concept of the persistence
    wizard which is currently only a list of features that are activated
    or not, without feedback on the information managed by each of them.

  - 4 should be easy to implement once we have 3 as removing packages
    from the list doesn't need any validity check. Note that we would
    always answer Yes to debconf questions.

  - 5 would require validating the packages added to the list to make
    sure that they can be installed. Installing packages on the fly as
    they are added to the list might help solving this.

  - We could merge both the **APT Packages** and **APT Lists**
    persistence features

Speed up installation
=====================

To solve [[!tails_ticket 9059 desc="#9059"]], which can currently block
the opening of the desktop for several minutes, we should investigate:

  - Starting reading packages lists and building cache on GDM PostLogin.
    For that we need an APT mechanism to do all this without installing
    or removing anything.

  - Installing packages once the session has started.

  - Using `nice` to not slow down the desktop too much in competition with
    `tails-upgrade-frontend`.

  - What kind of packages would suffer from being installed after the
    session started.

  - A notification mechanism for APT to be started after the session is
    ready.