Closed joraff closed 8 years ago
I think I'd prefer the use of a symlink...
Howcome? Curious, you've already given it thought, of course.
Would use of a payload key that was a hash help to solve the issues that Bom.txt tries to address?
I'd rather package projects be self-contained. Just a design choice on my part. And I want to keep the design simple. If it's possible to do something a little unusual without adding code, the "no-code" way will always be my preference. Thus, a symlink!
"Would use of a payload key that was a hash help to solve the issues that Bom.txt tries to address?" I don't see how. Can you explain?
Sure, you could:
{
"payload": [
{
"install_path": "/usr/local/munki/conditions",
"source": "/Users/joraff/dev/my_custom_conditions.py",
"mode": "100755",
"owner": "root or uid",
"group": "wheel or gid"
}
]
}
At build, optionally, we could insert the CRC from lsbom into the hash if it's really necessary.
Oh, I see. That's a level of complexity I'm really trying to avoid. If you want that flexibility/complexity both autopkg and The Luggage allow that sort of thing.
(I really just wanted something that built packages from a folder of files and a folder of scripts! That's it -- very simple and straightforward.)
Examples of using autopkg for this sort of thing: https://managingosx.wordpress.com/2015/07/30/using-autopkg-for-general-purpose-packaging/ https://github.com/gregneagle/autopkg-packaging-demo
Sometimes I'd like to store my payload files elsewhere (such as a munki conditional items scripts). Rather than implementing support for aliases or symbolic links, can we look for a payload key to enumerate and build a temporary folder structure when building?
Can do a PR if approved.