Please consider merging branch sbuild of repository https://git.spwhitton.name/propellor.
This branch adds the following features:
- A new module
Propellor.Property.Sbuildwith properties for configuring sbuild schroots - A new module
Propellor.Property.Schrootwith a property supporting those inPropellor.Property.Sbuild - A new module
Propellor.Property.Ccachewith a property supporting those inPropellor.Property.Sbuild - An export of
extractSuitefromPropellor.Property.Debootstrap, used inPropellor.Property.Sbuild - Two new types of iptables matching rules in
Propellor.Property.Firewall.
The additions to Propellor.Property.Firewall were made to support Sbuild.blockNetwork, which is a hack from the Debian Wiki which doesn't seem to work with the latest version of sbuild. I left the additions to Propellor.Property.Firewall in my branch since they are probably independently useful. I left the blockNetwork property commented-out in Sbuild.hs in case I or someone else can make it work at a later date.
I get the following strange warning from GHC thanks to my new export from Propellor.Property.Debootstrap. I can't figure out the problem and would be grateful for help.
src/Propellor/Property/Debootstrap.hs:8:9: Warning:
`extractSuite' is exported by `extractSuite' and `extractSuite'
--spwhitton
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.
Is the ~/.sbuildrc necessary to use the sbuild properties? If so, would it make sense to have a property that configures it?
You could use Utility.DataUnits for Ccache's MaxSize. This would be more flexible and consistent with other things in propellor.
Limit could be a monoid. This would perhaps simplify hasGroupCache as it could only be used once to set multiple limits.
Maybe instead of Ccache.hasGroupCache, call it Ccache.hasCache?
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.
Thanks for your feedback.
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 inPropellor.Property.Chrootwould be sufficient.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.
Done.
Done.
Done, I think that's better. I was originally thinking that the name
Ccache.hasCachemight be for a propertyUser -> 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 nameCcache.hasCachewould be needed.I'm on GHC 7.10.3, too...
Would it make sense to move the ~/.sbuildrc example into the documentation for the property that uses it?
I've copied the relevant part to the documentation for that property.
I'd like to retain the whole suggested ~/.sbuildrc content at the top of the haddock. The purpose of the suggested config.hs lines is to set up everything you need to be able to run sbuild with both piuparts and adt-run -- the "complete setup". You don't get all of that by just running
sbuild-createchrootfrom a command line. So having both the config.hs lines and the ~/.sbuildrc lines at the top of the haddock makes it clear what the module can do for the user.