summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2017-12-14 16:08:33 +0000
committerintrigeri <intrigeri@boum.org>2017-12-14 16:08:33 +0000
commitd0d14f82f654024baa36f58ef389ce62975add9f (patch)
tree79972acfb07a98761916ae221b8639ed745f6388
parentd3fffe0eb65ed9cd9657d0a1c41b9bbfa1e0334f (diff)
parent6d1c1e7db5453a550b289ec9cbb5e88ddc8c17fc (diff)
Merge remote-tracking branch 'origin/master'
-rw-r--r--wiki/src/blueprint/additional_software_packages.mdwn90
-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.mdwn (renamed from wiki/src/blueprint/additional_software_packages_offline_mode.mdwn)20
4 files changed, 115 insertions, 90 deletions
diff --git a/wiki/src/blueprint/additional_software_packages.mdwn b/wiki/src/blueprint/additional_software_packages.mdwn
index a644364..b0df5eb 100644
--- a/wiki/src/blueprint/additional_software_packages.mdwn
+++ b/wiki/src/blueprint/additional_software_packages.mdwn
@@ -1,96 +1,12 @@
-[[!meta title="User interface for additional software packages"]]
+[[!meta title="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.
-
-**FIXME**: 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
- 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.
+[[!map pages="blueprint/additional_software_packages/*" show=title]]
Notes
=====
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
index 0363fb5..5c1a6db 100644
--- a/wiki/src/blueprint/additional_software_packages_offline_mode.mdwn
+++ b/wiki/src/blueprint/additional_software_packages/offline_mode.mdwn
@@ -1,3 +1,5 @@
+[[!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]]
@@ -68,7 +70,19 @@ be installed.
This is the only remaining problem we should consider fixing.
-A solution for this problem would be:
+### 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.
-- in the *upgrade* operation : save a backup of @/var/lib/apt/lists/@ before running the @apt-get update@. On successful @apt-get upgrade@, remove the backup.
-- in the *install* operation : if there is a backup present, restore it before running @apt-get install@
+- 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.