| Age | Commit message (Collapse) | Author |
|---|
|
To get outertarget from the Propellor monad, the monad would have to be
parameteriszed with an outertarget type, since there's no single type.
For example:
newtype Propellor target p = Propellor { runWithHost :: RWST target () () IO p }
deriving (Monad, Applicative, Functor)
But then mkProperty becomes a problem, since the Propellor action
passed to it needs to already be of UnixLike type:
mkProperty :: Propellor UnixLike () -> Property UnixLike
mkProperty a = Property unixLike a
Could maybe live with that, but then `target` type check fails:
Expected type: Propellor (Targeting combinedtarget) ()
Actual type: Propellor (Targeting oldtarget) ()
Problem being that it's reusing the `a` which is a Propellor target ()
target newtarget (Property oldtarget a) = Property (intersectTarget oldtarget newtarget) a
And, the new Property has a different target, so it can't use the old `a`.
So, I'd need a way to cast one Propellor target () to a different target.
Maybe:
target newtarget (Property oldtarget (Propellor a)) =
let combinedtarget = intersectTarget oldtarget newtarget
in Property combinedtarget (Propellor (unsafeCoerce a))
But is that safe??
Even if it is, I can't see how to make ensureProperty get the outertarget
type. It returns Propellor (Targeting outertarget) (), which can read
the target from the RWST monad, but how to use that where the type of the
function is defined?
Rather than all that complication, it doesn't seem too bad to
require outertarget be passed to ensureProperty.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
propellor-config binary and not all the libraries.
This is a super speedup!
|
|
Got lost in recent changes and broke the cron job.
|
|
|
|
Works on debian stable!
|
|
|
|
|
|
|
|
|
|
|
|
The freebsd changes caused a bootstrap of a system with no declared OS to
not work, where before it was assumed to be some debian-like system where
apt can be used. Brought back this assumption.
|
|
|
|
|
|
|
|
|
|
|
|
better than symlinks because this way no conflict can ever occur
and, commit from hook
|
|
|
|
We were using checkResult instead of check, and we weren't parsing the
output of `jail -l -q` properly. Now it handles respins perfectly.
|
|
|
|
|
|
|
|
|
|
where blocks involve lest nesting than let in, and are more idiomatic
in propellor properties
|
|
|
|
Made some code a little faster..
|
|
for some reason I asked the author to put the copyright in there, but
Propellor doesn't do per-file copyrights; it's all BSD. Also, make the
maintainer show up in haddock.
|
|
This is so, when a user adds a new OS, ghc tells them everywhere they
need to look to add it.
Also, avoid throwing error from pure function..
|
|
Rather than having the property fail when the Host has no OS defined,
I made bootstrapPropellorCommand not install deps in this situation.
The cron job will (probably) still work, unless a system upgrade causes
deps to be removed.
|
|
|
|
|
|
|
|
|
|
The freebsd branch made it run ./propellor --check after verifying
that command fails, which is clearly wrong.
|
|
|
|
My policy for config.hs is it shouldn't need to load any modules other than
propellor and the desired property modules.
|
|
|
|
(cherry picked from commit df40046fd65bc07eced41adb73c7e227d2b54cd1)
|
|
(cherry picked from commit 0207c5ab585f41877c1b9f9674a25941cffd2ac7)
|
|
(cherry picked from commit c3a23f89092d1ef8367c37ab8993ea7031124f4b)
|
|
- Propellor bootstrapping
- Basic pkg
- Basic ZFS datasets and properties
- Simple Poudriere configuration (regular and ZFS)
- Poudriere jail creation
FIXME:
- Cron.hs: runPropellor needs the System, but hasn't yet gotten it.
Reorganizing:
- Remove FreeBSD.Process
- Move ZFS up to Property
- Add Info for Pkg.update/Pkg.upgrade
- Move FreeBSD.md to doc so it'll show up automatically.
- Merge the FreeBSD config with the other sample config.
- Use Info to check Pkg updated/upgraded and Poudriere configured.
- Warnings clean-up, move ZFS types to Propellor.Types.
- Maintainer and license statements.
|
|
|
|
|
