unixorn / luggage

Project to automate OS X package creation without using the packagemaker GUI
https://github.com/unixorn/luggage/wiki
391 stars 72 forks source link

Add support for pkgbuild #42

Closed ccaviness closed 11 years ago

ccaviness commented 11 years ago

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.

glarizza commented 11 years ago

Cool! I'll have to take a peek after work tonight. Thanks Clay!

glarizza commented 11 years ago

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!

timsutton commented 11 years ago

@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 ifeqs don't seem to be evaluated. This is about where my knowledge of make goes into a fuzzy haze.

Two other minor issues:

glarizza commented 11 years ago

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 :)

ccaviness commented 11 years ago

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...

glarizza commented 11 years ago

So, honestly, just moving the include underneath variable declarations in most examples might be the quick/dirty solution here, no?

timsutton commented 11 years ago

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.

ccaviness commented 11 years ago

In all of our Makefiles, we're doing:

USE_PKGBUILD=1 include ../path/to/luggage.make

OTHER_VARS=foo AND_SO_FORTH=bar

glarizza commented 11 years ago

Fuck it; Ship it :thumbsup:

ccaviness commented 11 years ago

Such a small change, no need to test Such a small change, no need to test

glarizza commented 11 years ago

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.

nobodygottimeforthat

Jaharmi commented 11 years ago

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!

justinrummel commented 11 years ago

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

glarizza commented 11 years ago

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 :)