diff options
Diffstat (limited to 'doc/todo')
10 files changed, 201 insertions, 0 deletions
diff --git a/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment b/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment new file mode 100644 index 00000000..bfa5e3b1 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 1" + date="2016-06-13T17:31:37Z" + content=""" +How would you see the integration of shell-monad or turtle? + +Do you have a preference? + +I actually use turtle and it is great! It may be more complete than shell-monad which may be an advantage or a disadvantage... +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment b/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment new file mode 100644 index 00000000..0779c49f --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment @@ -0,0 +1,39 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-06-13T20:23:37Z" + content=""" +One easy way would be something like: + + shellMonadProperty :: Control.Monad.Shell.Script Result -> Property UnixLike + +But, I don't know if that would really be useful. The better use case for +shell-monad seems to be where things like `userScriptProperty` take a +`Script`, that is currently an alias for `String`. Since shell-monad can +generate a shell script, it would be easy to write: + + shellMonad :: Control.Monad.Shell.Script () -> Script + +Or, perhaps change userScriptProperty to accept either a stringy-Script or +a shell monad Script, via a type class. Then it could be used like this: + + userScriptProperty (User "joey") $ do + cmd "echo" "hello" + cmd "rm" "/home/joey/something" + +Turtle seems to not have its own monad but simply uses MonadIO. So seems +you can use Turtle in the implementation of propellor properties the same as +other IO actions. Which is great, it should be easy to use it if you want +to. Something like: + + import Turtle.Prelude + + myProperty :: Property UnixLike + myProperty = property "my property using turtle" $ liftIO $ do + echo "hello" + rm "/something" + return NoChange + +But I don't think turtle can generate shell scripts like used by +`userScriptProperty`. +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment new file mode 100644 index 00000000..48d25d7f --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 3" + date="2016-06-14T10:56:04Z" + content=""" +I've posted a question on https://github.com/Gabriel439/Haskell-Turtle-Library/issues/157 + +Probably Gabriel will have a good idea for this :-). Maybe another solution would be to generate executables instead of shell scripts? + + +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment new file mode 100644 index 00000000..77f30917 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2016-06-14T17:11:09Z" + content=""" +We already have /usr/local/bin/propellor executable, so the cron job or +whatever could be made to run it with a parameter that runs the turtle IO +action. (Or generally, any IO action.. Being able to run arbitrary haskell +IO code as a cron job would be great!) + +This would need some way to get a `UniqueId` for an IO action, that is +stable across runs of propellor, and a way to build up a` Map UniqueId (IO ())` of such +actions. The Info interface could be used to build up that Map. + +---- + +Some of the places I'd like to use shell-monad though are where propellor +is bootstrapping itself on a host and all it can easily run at that point +is shell script. +"""]] diff --git a/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn b/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn index c8f3a195..7a22e976 100644 --- a/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn +++ b/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn @@ -1,3 +1,5 @@ Please consider merging branch `insecure-sbuild-keygen` from repo `https://git.spwhitton.name/propellor`. - Adds `Sbuild.keyringInsecurelyGenerated` which is useful on throwaway build VMs + +> [[merged|done]] --[[Joey]] 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. +"""]] |