summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/additional_software_packages
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/blueprint/additional_software_packages')
-rw-r--r--wiki/src/blueprint/additional_software_packages/dont_block_desktop_startup.mdwn23
-rw-r--r--wiki/src/blueprint/additional_software_packages/gui.mdwn72
-rw-r--r--wiki/src/blueprint/additional_software_packages/offline_mode.mdwn88
3 files changed, 183 insertions, 0 deletions
diff --git a/wiki/src/blueprint/additional_software_packages/dont_block_desktop_startup.mdwn b/wiki/src/blueprint/additional_software_packages/dont_block_desktop_startup.mdwn
new file mode 100644
index 0000000..d04b1a9
--- /dev/null
+++ b/wiki/src/blueprint/additional_software_packages/dont_block_desktop_startup.mdwn
@@ -0,0 +1,23 @@
+[[!meta title="Better manage installation and update of additional software packages"]]
+
+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.
+
diff --git a/wiki/src/blueprint/additional_software_packages/gui.mdwn b/wiki/src/blueprint/additional_software_packages/gui.mdwn
new file mode 100644
index 0000000..a48c6b9
--- /dev/null
+++ b/wiki/src/blueprint/additional_software_packages/gui.mdwn
@@ -0,0 +1,72 @@
+[[!meta title="User interface for additional software packages"]]
+
+<div class="note">
+[[blueprint/remember_installed_packages]] overlaps with
+this blueprint.
+</div>
+
+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 restarted. ([[!tails_ticket 9819 desc="#9819"]])
+
+We are going to implement this feature for Tails 3.7 ([[!tails_ticket 9059 desc="#14593"]])
+
+Proposed user experience
+========================
+
+0. Have a way to enable the feature (and its dependencies) in
+*tails-persistence-setup*. This besically means cheking both
+*APT Lists* and *APT Packages Cache* (much welcome)
+
+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.
+
+**XXX**: long-term wise, we should probably focus on _GNOME
+Software_ instead of _Synaptic_; if something works for both, fine,
+but the PackageKit D-Bus interface might be easier to support than
+hooking APT/dpkg, so one option would be to only support installation
+& removal done via PackageKit (i.e. either with _GNOME Software_ or
+using `pkcon` on the command line) and not operations done directly
+with `apt` or _Synaptic_.
+
+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 (welcome).
+
+5. Allow adding packages to the list in 3 (we don't really want that, do we?).
+
+Implementation
+--------------
+
+ - 1 and 2 might be possible to implement using APT hooks or PackageKit
+ DBus interface. We need to
+ investigate how these hooks would communicate with the desktop
+
+ - 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
diff --git a/wiki/src/blueprint/additional_software_packages/offline_mode.mdwn b/wiki/src/blueprint/additional_software_packages/offline_mode.mdwn
new file mode 100644
index 0000000..5c1a6db
--- /dev/null
+++ b/wiki/src/blueprint/additional_software_packages/offline_mode.mdwn
@@ -0,0 +1,88 @@
+[[!meta title="Offline mode for additional software packages"]]
+
+This is about [[!tails_ticket 14570]] which we plan to implement for Tails 3.5.
+
+[[!toc levels=2]]
+
+# Goal
+
+Have Additional software packages to work offline forever, but to upgrade when connecting to the Internet.
+
+# Current status
+
+According to [[!tails_ticket 6260]] Additional Software Packages works offline for a dew days after being connected, but then fails.
+
+We researched the possible root causes of this class of issues and
+identified three:
+
+## APT indices have expired
+
+This was the hypothesis on [[!tails_ticket 6260]].
+
+Release file corresponding to the packages to be installed is expired.
+This is controlled by the `Valid-Until` field of the Release file
+(<https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until>).
+
+Looking at Valid-Until fields on Tails, it seems to be :
+
+- ~1 week for unstable and stable/update
+- ~1 month for torproject.org
+- unlimited for stable
+
+Testing and study of the APT source code show that this problem does
+not exist anymore on Tails 3.3: APT checks the indices expiration date
+only when it downloads them, not when it reads them to
+install packages.
+
+### Testing procedure
+
+I tried installing packages offline in Tails 3.3 using the following procedure on 14 Dec 2017:
+
+* start Tails online with persistence of apt packages and apt lists
+* install optipng (currently pulled from stretch/updates, which expires on 22 Dec 2017) and wdiff (from stretch, which doesn't expire) and add them to additional software list
+* reboot offline
+* the install works and optipng version is the one from stretch/updates
+* set the date 1 year in the future in the BIOS
+* reboot offline
+* the install works and optipng version is the one from stretch/updates
+
+I went through the entire procedure 3 times and got the same results.
+Basic offline operation is thus already working, and
+[[!tails_ticket 6260]] seems to be have been resolved: recent APT
+doesn't check Valid-Until on package installation.
+
+## One of the packages was not cached in the first place
+
+When I run Tails 3.3, install a package with `apt` and add it to my
+list of Additional Software Packages, then if I am offline when
+I start Tails the next time, this package won't be installed.
+
+The root cause of this problem was identified and a fix has been
+committed for Tails 3.5 ([[!tails_ticket 10958]]).
+
+## Incomplete online upgrade process
+
+Assume that during an online Tails session, the APT indices are
+successfully updated, but then Tails is shut down before the upgraded
+Debian packages were downloaded. Then, if Tails is started offline the
+next time, the packages that needed to be upgraded cannot
+be installed.
+
+This is the only remaining problem we should consider fixing.
+
+### Proposed solution
+
+- in the *upgrade* operation : save the content `/var/lib/apt/lists/` before running the `apt-get update`. It could be stored to a specific location, e.g. `/live/persistence/TailsData_unlocked/tails-additional-software/working_apt_lists/`. After a successful `apt-get upgrade`, remove the *working_apt_lists*.
+- in the *install* operation : if there is a backup present, restore it before running `apt-get install`
+
+### Testing procedure
+
+We should find a testing procedure, which doesn't look trivial, as the problem only occurs when there is an upgrade of an additional software package.
+
+- setup **offline** tails with persistence including *APT lists* and *APT cache*
+- setup an *Additional Software Package* that has been upgraded in the last point release
+- copy lists before the last Debian point release to `/var/lib/apt/lists`
+- copy the old version of the package in `/val/lib/apt/archives`
+- reboot online. The installation should work.
+- reboot online and cut the network after APT update, but before the upgrade. The lists should be uptodate, but the packages not updated.
+- reboot offline. The installation should currently fail.