summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/Debootstrap.built_should_install_the_relevant_archive_keyring_package.mdwn5
-rw-r--r--doc/todo/Sbuild_support_for_Buntish.mdwn4
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_1_1b75bf6efd01918f0a4db958ba8afe2b._comment14
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_2_9bd0cc2462c12d1746b7dbf2496ebfee._comment10
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_3_81d771c54f1baac80a2ac93e4534d7a9._comment64
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_4_c9f3103d192017a3291b82969dfd34f6._comment9
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_5_e976f396ed6e0aa596fed5c7777e08a0._comment10
-rw-r--r--doc/todo/Sbuild_support_for_Buntish/comment_6_8727a5eba0ae8daddba8a023dc845837._comment8
-rw-r--r--doc/todo/serialize_actions_via_free_applicative.mdwn34
-rw-r--r--doc/todo/unpropelling_a_host/comment_2_fb572083e8f8bccef037d43a4f7487c2._comment8
10 files changed, 166 insertions, 0 deletions
diff --git a/doc/todo/Debootstrap.built_should_install_the_relevant_archive_keyring_package.mdwn b/doc/todo/Debootstrap.built_should_install_the_relevant_archive_keyring_package.mdwn
new file mode 100644
index 00000000..23fa65ef
--- /dev/null
+++ b/doc/todo/Debootstrap.built_should_install_the_relevant_archive_keyring_package.mdwn
@@ -0,0 +1,5 @@
+Attempting to build a Buntish chroot using Debootstrap.built on a Debian host fails until the user installs the ubuntu-archive-keyring package.
+
+Debootstrap.built should ensure that the relevant *-archive-keyring package is installed before invoking debootstrap(1).
+
+--spwhitton
diff --git a/doc/todo/Sbuild_support_for_Buntish.mdwn b/doc/todo/Sbuild_support_for_Buntish.mdwn
new file mode 100644
index 00000000..43a5d2d1
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish.mdwn
@@ -0,0 +1,4 @@
+Property.Sbuild claims to support Buntish Oses, but for me it fails in Apt.stdSourcesList, because that function currently (5.6.1) only supports
+Debian. I suppose the right solution is to extend Apt.stdSourcesList, but maybe Property.Sbuild should do it's own thing?
+
+> Patch applied (and it is an API change) [[done]] --[[Joey]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_1_1b75bf6efd01918f0a4db958ba8afe2b._comment b/doc/todo/Sbuild_support_for_Buntish/comment_1_1b75bf6efd01918f0a4db958ba8afe2b._comment
new file mode 100644
index 00000000..241e62e4
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_1_1b75bf6efd01918f0a4db958ba8afe2b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-06T19:35:16Z"
+ content="""
+In a way the problem is that schrootProps uses toChildProperty,
+which bypasses Propellor's type-level OS system.
+
+I think it may be possible to move the use of Apt.stdSourcesList
+out of Sbuild.built', and have the user pass those properties into it,
+along with the OS property and their other desired properties,
+and let propellor type check that the properties passed to it all work
+together.
+"""]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_2_9bd0cc2462c12d1746b7dbf2496ebfee._comment b/doc/todo/Sbuild_support_for_Buntish/comment_2_9bd0cc2462c12d1746b7dbf2496ebfee._comment
new file mode 100644
index 00000000..809daba1
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_2_9bd0cc2462c12d1746b7dbf2496ebfee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 2"
+ date="2019-03-06T21:39:13Z"
+ content="""
+When implementing the Sbuild module we discussed the use of toChildProps and concluded that it was inevitable.
+
+However, if requiring the user to pass things around a bit more is the price for making the Sbuild module work for other OSs, we had better do it.
+"""]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_3_81d771c54f1baac80a2ac93e4534d7a9._comment b/doc/todo/Sbuild_support_for_Buntish/comment_3_81d771c54f1baac80a2ac93e4534d7a9._comment
new file mode 100644
index 00000000..435af1a2
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_3_81d771c54f1baac80a2ac93e4534d7a9._comment
@@ -0,0 +1,64 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-03-06T22:11:45Z"
+ content="""
+Something like this (only tested it compiles):
+
+ diff --git a/src/Propellor/Property/Sbuild.hs b/src/Propellor/Property/Sbuild.hs
+ index 8cc2e3bec..25d5f6236 100644
+ --- a/src/Propellor/Property/Sbuild.hs
+ +++ b/src/Propellor/Property/Sbuild.hs
+ @@ -29,6 +29,7 @@ Suggested usage in @config.hs@:
+ > where
+ > sidSchrootBuilt = Sbuild.built Sbuild.UseCcache $ props
+ > & osDebian Unstable X86_32
+ +> & Sbuild.standard
+ > & Sbuild.update `period` Weekly (Just 1)
+ > & Sbuild.useHostProxy mybox
+
+ @@ -64,6 +65,7 @@ module Propellor.Property.Sbuild (
+ built,
+ -- * Properties for use inside sbuild schroots
+ update,
+ + standard,
+ useHostProxy,
+ -- * Global sbuild configuration
+ -- blockNetwork,
+ @@ -126,7 +128,7 @@ built'
+ -> String
+ -> String
+ -> RevertableProperty (HasInfo + DebianLike) Linux
+ -built' cc (Props ps) suite arch = provisioned <!> deleted
+ +built' cc ps suite arch = provisioned <!> deleted
+ where
+ provisioned :: Property (HasInfo + DebianLike)
+ provisioned = combineProperties desc $ props
+ @@ -220,10 +222,7 @@ built' cc (Props ps) suite arch = provisioned <!> deleted
+
+ -- the schroot itself
+ schroot = Chroot.debootstrapped Debootstrap.BuilddD
+ - schrootRoot (Props schrootProps)
+ - schrootProps =
+ - ps ++ [toChildProperty Apt.stdSourcesList
+ - , toChildProperty $ Apt.installed ["eatmydata", "ccache"]]
+ + schrootRoot ps
+
+ -- static values
+ suiteArch = suite ++ "-" ++ arch
+ @@ -251,6 +250,14 @@ built' cc (Props ps) suite arch = provisioned <!> deleted
+ where
+ base = ["eatmydata"]
+
+ +-- | Some properties that will be wanted in most any Debian schroot.
+ +--
+ +-- Compiler caching, eatmydata, and standard apt sources.
+ +standard :: Property Debian
+ +standard = propertyList "standard sbuild properties" $ props
+ + & Apt.stdSourcesList
+ + & Apt.installed ["eatmydata", "ccache"]
+ +
+ -- | Ensure that an sbuild schroot's packages and apt indexes are updated
+ --
+ -- This replaces use of sbuild-update(1).
+"""]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_4_c9f3103d192017a3291b82969dfd34f6._comment b/doc/todo/Sbuild_support_for_Buntish/comment_4_c9f3103d192017a3291b82969dfd34f6._comment
new file mode 100644
index 00000000..10d12d46
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_4_c9f3103d192017a3291b82969dfd34f6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Works on my machine ;)"
+ date="2019-03-16T00:19:05Z"
+ content="""
+I had to hand apply most of Joey's patch for reasons that escape me, but it seems to work OK. I just built an ubuntu chroot and used sbuild to build a package in it. I did have to copy part of the definition of standard into my own setup code (the installation of \"eatmydata\" and \"ccache\"). So maybe there is something that could be made smoother there.
+
+"""]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_5_e976f396ed6e0aa596fed5c7777e08a0._comment b/doc/todo/Sbuild_support_for_Buntish/comment_5_e976f396ed6e0aa596fed5c7777e08a0._comment
new file mode 100644
index 00000000..876ef434
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_5_e976f396ed6e0aa596fed5c7777e08a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 5"
+ date="2019-03-18T01:35:38Z"
+ content="""
+`Sbuild.builtFor` assumes that ccache and eatmydata are installed, so I think that those need to be moved out of `Sbuild.standard` and back where they were.
+
+David, have you tested that Debian schroots still work with Joey's patch?
+"""]]
diff --git a/doc/todo/Sbuild_support_for_Buntish/comment_6_8727a5eba0ae8daddba8a023dc845837._comment b/doc/todo/Sbuild_support_for_Buntish/comment_6_8727a5eba0ae8daddba8a023dc845837._comment
new file mode 100644
index 00000000..0c3449c7
--- /dev/null
+++ b/doc/todo/Sbuild_support_for_Buntish/comment_6_8727a5eba0ae8daddba8a023dc845837._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="patch submitted"
+ date="2019-03-29T23:29:22Z"
+ content="""
+I've e-mailed a tested patch to Joey, CCing David.
+"""]]
diff --git a/doc/todo/serialize_actions_via_free_applicative.mdwn b/doc/todo/serialize_actions_via_free_applicative.mdwn
new file mode 100644
index 00000000..8659e76e
--- /dev/null
+++ b/doc/todo/serialize_actions_via_free_applicative.mdwn
@@ -0,0 +1,34 @@
+A persistent problem with propellor is that Propellor actions cannot be
+compared for equality or serialized.
+
+This prevents eg, propellor outside a chroot from passing a Property to run
+to the propellor running inside the chroot. (Because Property contains
+a Propellor action.) A workaround is used, that gives the
+Property a name at compile time.
+
+Another problem is that Propellor actions currently run whatever IO they
+perform, and can't be examined in a no-op mode.
+
+If Propellor actions were somehow represented as an AST, all these problems
+would be eliminated; they could be serialized, compared, examined, and run
+in modes that don't really run them.
+
+(This might also allow the local propellor to ship the AST off to the
+remote propellor to run, without the remote propellor needing to be
+rebuilt, if they share the same version of the AST.)
+
+Unfortunately, a free Monad can't be serialized, it's an AST but an AST
+embedding haskell functions. However, a free Applicative can apparently be
+serialized.
+
+See <https://www.cs.ox.ac.uk/jeremy.gibbons/publications/delivery.pdf>
+and <https://www.reddit.com/r/haskell/comments/7rlgu2/serialize_a_program_written_in_a_free_monad/>
+
+Question is, would an Applicative building an AST be sufficient for
+everything that a Propellor action needs to do?
+
+This needs some investigation of the kind of IO that Propellor actions do.
+Much of it, I suspect is not very monadic, in that it mostly does some IO
+and returns a Result, rather than building up complex IO sequences based on
+previous inputs. --[[Joey]]
+
diff --git a/doc/todo/unpropelling_a_host/comment_2_fb572083e8f8bccef037d43a4f7487c2._comment b/doc/todo/unpropelling_a_host/comment_2_fb572083e8f8bccef037d43a4f7487c2._comment
new file mode 100644
index 00000000..728e3fae
--- /dev/null
+++ b/doc/todo/unpropelling_a_host/comment_2_fb572083e8f8bccef037d43a4f7487c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="Patch series submitted"
+ date="2019-04-01T17:21:40Z"
+ content="""
+I've just mailed patches addressing this to Joey.
+"""]]