FEATURE REQUEST: new installer type, copyitems about munki HOT 11 CLOSED

From [email protected] on July 21, 2010 14:37:25

I've been thinking about something similar, but more generic, where you could define the (relative) path from the DMG and the destination path on the startup disk.

An example:

source_path
SomeDumbPhotoshopPlugin.plugin

destination_path
Applications/Photoshop CS4/Plug-ins/File Formats

and assuming the same plugin works with Photoshop CS5, you could create a second pkginfo item using the same disk image, but with a different destination_path:

destination_path
Applications/Photoshop CS5/Plug-ins/File Formats

Status: Accepted
Labels: -Type-Defect Type-Enhancement

from munki.

From [email protected] on July 21, 2010 14:40:03

Yes, this source_path and destination_path is more like it.

from munki.

From [email protected] on July 21, 2010 14:41:52

Ummm, as I am new to using this GoogleCode, how do I set up the issue type, I do not see any place where to define if it is Defect, Enhancement or some other...?

from munki.

From [email protected] on July 21, 2010 14:47:49

Probably with this new kind of approach you could also consider including support for set permissions array per item? A there may still be some stupid items/plugins which require that some specific admin user has read+write permissions on that item...

from munki.

From [email protected] on July 21, 2010 14:52:06

"Ummm, as I am new to using this GoogleCode, how do I set up the issue type, I do not see any place where to define if it is Defect, Enhancement or some other..."

In the Labels, click the one where "Type-Defect" is pre-entered, and change it to "Type-Enhancement". Feel free to set your idea of the Priority as well.

from munki.

From [email protected] on July 21, 2010 14:53:27

"Probably with this new kind of approach you could also consider including support for set permissions array per item? A there may still be some stupid items/plugins which require that some specific admin user has read+write permissions on that item..."

No, if you need that, repackage.

from munki.

From [email protected] on July 23, 2010 15:00:58

I've been looking at how hard it would be to support copying multiple items from a disk image. As I expected, the data format isn't difficult. It would look something like:

{{{
items_to_copy


source_item
Google Earth.app
destination_path
/Applications
user
root
group
admin
mode
ug-w


source_item
Google Earth Web Plug-in.plugin
destination_path
/Library/Internet Plug-ins
user
root
group
admin
mode
ug-w


}}}

But making a usable interface to makepkginfo to help create pkginfo files with a list like this seems hard. Is it worth doing, or should we limit ourselves to copying a single item from a disk image, and use multiple pkginfo items if we want to copy multiple items?

from munki.

From [email protected] on July 23, 2010 23:33:14

I am used to check manually through all newly-generated pkginfo-files and in many cases I have to do some manual editing on them.
And I am always generating pkginfo-files with .plist suffix so I can more easily access them manually with Property List Editor or TextWrangler.

For me it is not an issue if I have to copy and paste some array items from another pkginfo-file to another.
Although it is not always easy to check a plist manually if you have made an error while editing but usually takes just a couple of minutes to fix it.
And you can always use a previous pkginfo version of the similar pkginfo as a base for the new version.
Usually I create a new pkginfo file from a new version of pkg/app and compare the changes between old and new version.
So I would vote for building that items_to_copy-functionality with multiple items support within one pkginfo-file and leave that development of makepkginfo for a later date.

from munki.

From [email protected] on August 02, 2010 11:51:53

This has been released with munki tools 0.6.0.633.0. The new install type is called "copy_from_dmg". makepkginfo supports a single item to be copied, but the plist format supports an arbitrary number of items to be copied.

Status: Fixed

from munki.

From [email protected] on August 02, 2010 15:18:57

Initially tested copy_from_dmg with munki tools 0.6.0.640.0.
Works with .app, files and folders copied to /Applications and some other specific locations.

And those special file permissions work also if defined correctly in pkginfo.

If copying plain folders/files without any .app in .dmg one have to create pkginfo file manually (or use an existing pkginfo as a template).
And installs-definitions are crucial with this kind of install method as munki has to know where those "special" items were put so it can remove them later if needed.

Thanks, is there any way I could donate to you or someone else?

from munki.

From [email protected] on August 02, 2010 16:09:35

"If copying plain folders/files without any .app in .dmg one have to create pkginfo file manually (or use an existing pkginfo as a template)."

You should be able to use makepkginfo with the --item and --destinationpath flags in this case.

from munki.