Closed ccaviness closed 11 years ago
Cool! I'll have to take a peek after work tonight. Thanks Clay!
Pulled this down and tested it out:
$sudo USE_PKGBUILD=1 make pkg
/usr/local/share/luggage/luggage.make:192: warning: overriding commands for target `scriptdir'
/usr/local/share/luggage/luggage.make:186: warning: ignoring old commands for target `scriptdir'
make -e pack-munki-certs
/usr/local/share/luggage/luggage.make:192: warning: overriding commands for target `scriptdir'
/usr/local/share/luggage/luggage.make:186: warning: ignoring old commands for target `scriptdir'
If you need to override permissions or ownerships, override modify_packageroot in your Makefile
Creating /tmp/the_luggage/MunkiCerts-1.0.0/payload/MunkiCerts-1.0.0.pkg with /usr/bin/pkgbuild.
sudo /usr/bin/pkgbuild --root /tmp/the_luggage/MunkiCerts-1.0.0/root \
--identifier com.company.MunkiCerts \
--filter "/CVS$" --filter "/\.svn$" --filter "/\.cvsignore$" --filter "/\.cvspass$" --filter "/(\._)?\.DS_Store$" --filter "/\.git$" --filter "/\.gitignore$" \
--scripts /tmp/the_luggage/MunkiCerts-1.0.0/scripts \
--version 1.0.0 \
--ownership preserve \
/tmp/the_luggage/MunkiCerts-1.0.0/payload/MunkiCerts-1.0.0.pkg
pkgbuild: Inferring bundle components from contents of /tmp/the_luggage/MunkiCerts-1.0.0/root
pkgbuild: Wrote package to /tmp/the_luggage/MunkiCerts-1.0.0/payload/MunkiCerts-1.0.0.pkg
Inspecting the package, things look good!
@justinrummel and I were looking at the functionality in ##osx-server, and I noticed that PKGBUILD=1 only takes effect if it's defined in luggage.local or before the luggage.make include. I assume this is due to the way make exports variables.
If it's instead included later in the Makefile (and not in luggage.local), it looks to me as though it evaluates PKGBUILD for pack-script at line 743, because we at least see the help text appear. But other ifeq
s don't seem to be evaluated. This is about where my knowledge of make goes into a fuzzy haze.
Two other minor issues:
Just glancing at this now, but I'm assuming because make evaluates procedurally, that variables being declared AFTER the include statement would not be evaluated how you would expect. It makes sense that I didn't catch this because I set the environment variable while running the command:
$ sudo USE_PKGBUILD=1 make pkg
Open an issue for this, and then submit a pull request for the minor issues (if you feel comfortable). Also, if you feel comfortable taking a stab at the greater issue at hand, that would be totally awesome. If not, just documenting it with an issue would be great too :)
We're setting USE_PKGBUILD=1 before the include everywhere, yes.
Trying to do elegant Make is ... nearly impossible.
Frankly, I think there should just be a move to default to pkgbuild and drop PackageMaker support entirely, but that does leave a lot of existing Makefiles to be updated...
So, honestly, just moving the include underneath variable declarations in most examples might be the quick/dirty solution here, no?
I agree - I'd looked briefly at doing the pkgbuild support last summer but tried to at the same time support backwards compatibility for postflight script filenames and the PM_RESTART override (which involves customizations to the PackageInfo file), and decided I was in way over my head with make.
On 2013-01-24, at 4:56 PM, Clay Caviness notifications@github.com wrote:
We're setting USE_PKGBUILD=1 before the include everywhere, yes.
Trying to do elegant Make is ... nearly impossible.
Frankly, I think there should just be a move to default to pkgbuild and drop PackageMaker support entirely, but that does leave a lot of existing Makefiles to be updated...
— Reply to this email directly or view it on GitHub.
In all of our Makefiles, we're doing:
USE_PKGBUILD=1 include ../path/to/luggage.make
OTHER_VARS=foo AND_SO_FORTH=bar
Fuck it; Ship it :thumbsup:
Such a small change, no need to test
I had actually thought about the need for tests before I merged the PKGBUILD commit - just in case shit happened. Even some simple unit tests with expected behavior would be fine. It looks like there are some unit testing frameworks around make buildfiles, but, frankly, I'm not sure (with as few contributors as we have) who would be in charge of maintaining those. It's certainly worth an issue, but if you thought WRITING Makefiles was bad, imagine TESTING that shit.
The previous default for Luggage built 10.4-compatible pkgs. I'd like to see a reasonably complete list of the effects from switching to pkgbuild for existing packages (including their requirements, resources, payload, and scripts) that would have been built with that previous default in mind.
I'm playing catch-up on pkgbuild, so this would certainly help me grok this change. Thanks!
What if the focus was to move forward with pkgbuild as the default, but have the option of using USE_PKGBUILD=0 in a Makefile (vs. a luggage.local or setting it prior to the include)?
The primary difference between PM and PB that I can quickly see is PB will spit out FLAT pkg files. Scripts must be named named preinstall and/or postinstall (vs. preflight / postflight). PM does accept these as script file names for backwards compatibility.
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/packagemaker.1.html http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
Let's move this to the list, please. I have a feeling we're stacking a great deal if useful information into a closed Pull Request that nobody will see :)
Add support for pkgbuild. To use, add USE_PKGBUILD=1 to your Makefile (or override for everything in luggage.local), and ensure your package scripts are correctly named (preinstall/postinstall in the brave new pkgbuild world).
Also tweak location of luggage.local import, and ensure environment variables are preserved so $STAMP and other time-sensitive variables aren't re-evaluated in sub-makes.