summaryrefslogtreecommitdiff
path: root/doc/todo/merge_request:_changes_to_Reboot.hs
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/merge_request:_changes_to_Reboot.hs')
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment26
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment11
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment23
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment29
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment29
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment13
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment13
7 files changed, 144 insertions, 0 deletions
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment
new file mode 100644
index 00000000..a1a72054
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-06-13T22:59:56Z"
+ content="""
+While I've merged this, I am unsure if Reboot.toKernelNewerThan
+should stop propellor from ensuring any subsequent properties.
+
+That works if we have:
+
+ & toKernelNewerThan foo
+ & Sbuild.built
+
+But not if the two properties are flipped. So, doesn't it follow
+that Sbuild.built is a buggy property?
+
+If Sbuild.built needs a particular kernel version running,
+it could requires toKernelNewerThan. Then any use of Sbuild.built
+would make sure the right kernel is running, rebooting into it if
+necessary.
+
+And, if toKernelNewerThan failed due to the right kernel version not being
+installed, Sbuild.built would be prevented from running. In which case, it
+would be fine for propellor to continue on with ensuring other unrelated
+properties.
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment
new file mode 100644
index 00000000..fa1048a3
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-06-13T23:13:28Z"
+ content="""
+readVersionMaybe was buggy; for "4.1.2" it yielded
+`Just (Version {versionBranch = [4], versionTags = []})`
+which is lacking anything but the major.
+
+I fixed it by taking the maximum of the list of all possible parses.
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment
new file mode 100644
index 00000000..4fa14683
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 3"
+ date="2016-06-14T03:16:18Z"
+ content="""
+Thanks for taking a look at my branch, and especially for fixing my inadequately-tested `readVersionMaybe`.
+
+`Sbuild.built` does not *require* a particular version of the kernel. It is just that the file that it generates in `/etc/schroot/chroot.d` can vary depending on the kernel version running at the time that `Sbuild.built` is first ensured. In particular, if the running kernel does not support overlayfs (as jessie's kernel doesn't), the line `union-type=overlay` will be omitted from the file in `/etc/schroot/chroot.d`. This renders `Schroot.overlaysInTmpfs` useless.
+
+I think it should be up to the user to apply a property like
+
+ & Sbuild.built foo `requires` Reboot.toKernelNewerThan bar
+
+to individual hosts, because it depends on whether they actually care about using an overlay chroot. Perhaps on an old machine they don't intend to use overlays. In my config, I do something like this:
+
+ & osDebian Testing \"i386\"
+ & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan \"4\")
+ & Sbuilt.builtFor ...
+
+The idea is that if I reinstall my machine from a jessie installation CD, propellor will upgrade to testing and boot to the new kernel before it builds the chroot, so I get the `union-type=overlay` line in my config.
+
+I could prepare a patch to add this information to the haddock of Sbuild.hs?
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment
new file mode 100644
index 00000000..3d842ac3
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-06-14T04:04:50Z"
+ content="""
+It might also be worth making the Sbuild properties know
+whether overlays are desired. Then they could make sure to set up the
+config file with the needed lines, even if the wrong kernel is running.
+
+I assume schroot fails to work in that configuration, so the properties
+for it would fail and then the user would notice they need to add a
+property to get a new enough kernel version..
+
+It could be specified with another parameter to the Sbuild properties.
+Or, you could add a pure Info property `useOverlays` and have the
+Sbuild properties check if the Info has that set. This would also
+let Schroot.overlaysInTmpfs require useOverlays and auto-enable them.
+
+Most of the implementation of that:
+
+ useOverlays :: Property (HasInfo + UnixLike)
+ useOverlays = pureInfoProperty "use schroot overlays" (InfoVal UseOverlays)
+
+ data UseOverlays = UseOverlays
+
+ useOverlays :: Propellor Bool
+ useOverlays = isJust . fromInfoVal
+ <$> (askInfo :: Propellor (InfoVal UseOverlays))
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment
new file mode 100644
index 00000000..148f8efb
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-06-14T03:41:53Z"
+ content="""
+When `requires` is used as in your first example, Reboot.toKernelNewerThan
+does not need to throw an exception. It could just return FailedChange
+and then Sbuild.builtFor wouldn't get run.
+
+Your second example, as written is actually buggy. If Apt.upgraded
+fails for some reason, then Reboot.toKernelNewerThan never gets run,
+and then Sbuilt.builtFor can still run with the wrong kernel version.
+
+The second example could instead be written thus:
+
+ & osDebian Testing "i386"
+ & combineProperties "sbuild setup"
+ ( props
+ & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan "4")
+ & Sbuilt.builtFor ...
+ )
+
+Then if any part of the upgrade fails the following properties don't run
+thanks to `combineProperties`. And here too Reboot.toKernelNewerThan does
+not need to thow an exception.
+
+So, I'm not seeing any good use cases for it throwing an exception in these
+examples.
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment
new file mode 100644
index 00000000..05ca43ae
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 6"
+ date="2016-06-16T06:30:04Z"
+ content="""
+I like the idea of a `useOverlays` info property. It is better, and more in the spirit of propellor, to have the choice explicit, rather than implicitly relying on the behaviour of certain shell commands in certain conditions (relying on sbuild-createchroot(1) to create the config file in /etc/schroot/chroot.d is the thing I like least about Sbuild.hs, though it's necessary for achieving the goal of having a totally standard Debian sbuild setup).
+
+Before I implement this, I have a couple of questions:
+
+1. In the case where `Reboot.toKernelNewerThan` finds a satisfactory kernel to reboot to, what do you think about the choice of rebooting immediately or at the end of the current propellor run? If every property that needs the newer kernel `requires` it, it would mean that other properties that don't need the newer kernel get ensured sooner. Not sure whether this is actually an advantage, but it might encourage using `requires` instead of relying on implicit ordering.
+
+2. You suggest relying on schroot(1) and sbuild-createchroot(1) failing if `union-type=overlay` is present in the config file but the kernel doesn't support overlays. I'd prefer to go further and have the sbuild properties conditionally `requires` `Reboot.toKernelNewerThan` if the info property is set. That way, we can be confident that we'll never get an inconsistent state out of the sbuild properties. Does this sound sensible?
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment
new file mode 100644
index 00000000..5898e0a5
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-06-17T01:21:08Z"
+ content="""
+If Reboot.toKernelNewerThan doesn't reboot right away, then
+when a property `requires` it, the property's code is not
+guaranteed to run under the new kernel.
+So, an immediate reboot seems to make sense.
+
+Making the sbuild properties automatically include
+Reboot.toKernelNewerThan seems reasonable.
+"""]]