From fe80b0157c0de7c2a2155e5d268b965c3a0f443d Mon Sep 17 00:00:00 2001 From: spwhitton Date: Sun, 22 May 2016 01:48:28 +0000 Subject: Added a comment --- ...ent_2_d8afe7b1fd49df5794c9abf2be732f8b._comment | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 doc/todo/merge_request:_Propellor.Property.Sbuild/comment_2_d8afe7b1fd49df5794c9abf2be732f8b._comment (limited to 'doc/todo/merge_request:_Propellor.Property.Sbuild/comment_2_d8afe7b1fd49df5794c9abf2be732f8b._comment') diff --git a/doc/todo/merge_request:_Propellor.Property.Sbuild/comment_2_d8afe7b1fd49df5794c9abf2be732f8b._comment b/doc/todo/merge_request:_Propellor.Property.Sbuild/comment_2_d8afe7b1fd49df5794c9abf2be732f8b._comment new file mode 100644 index 00000000..44a2a542 --- /dev/null +++ b/doc/todo/merge_request:_Propellor.Property.Sbuild/comment_2_d8afe7b1fd49df5794c9abf2be732f8b._comment @@ -0,0 +1,58 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 2" + date="2016-05-22T01:48:27Z" + content=""" +Thanks for your feedback. + +> Re not running propellor in the sbuild chroot, I have in the past used +> schroot for things where it would have made sense to run propellor in +> the chroot. OTOH, systemd-container is a better fit for such uses +> cases now, probably. + +I was thinking that if someone wanted to use a schroot and run +propellor in it, useful properties could be appended to +`Propellor.Property.Schroot`. As far as types go, I think that the +types in `Propellor.Property.Chroot` would be sufficient. + +> Is the ~/.sbuildrc necessary to use the sbuild properties? If so, +> would it make sense to have a property that configures it? + +The only probably which *needs* the suggested ~/.sbuildrc is +`Sbuild.piupartsConfFor`. With the other properties and no +~/.sbuildrc, you should be able to go ahead and use sbuild(1) to +perform a clean build. + +I don't think there is a way to write a non-intrusive property to add +anything to a user's ~/.sbuildrc. That's because they will probably +have different preferences for the options to pass to piuparts than I +give in the example, and we would have to merge the adt-run code with +any existing post-build-commands. I'm not sure propellor should have +a perl config file parser. + +> You could use Utility.DataUnits for Ccache's MaxSize. This would be +> more flexible and consistent with other things in propellor. + +Done. + +> Limit could be a monoid. This would perhaps simplify hasGroupCache as +> it could only be used once to set multiple limits. + +Done. + +> Maybe instead of Ccache.hasGroupCache, call it Ccache.hasCache? + +Done, I think that's better. I was originally thinking that the name +`Ccache.hasCache` might be for a property `User -> Property +DebianLike`. However, if someone wanted to write a property configuring +a user cache, it would probably have the standard location +`~/.ccache`. This cache would be implicitly created when required, so +the name `Ccache.hasCache` would be needed. + +> That is a weird build warning! But, I don't see it with ghc +> 7.10.3. Normally you'd see that warning when the module's export list +> exported the same symbol twice. + +I'm on GHC 7.10.3, too... + +"""]] -- cgit v1.2.3