Talk:Installer (macOS)

It's worth it for the screenshot alone

I have never seen it before, I'm sure there is some more that could be added to the article, but since I don't own a Mac, I really can't help. I am interested to how installers work on other OSes, because of the dismal state I have found them to be on Linux. Autopackage is coming though.--Terrible Tim 11:27, 17 May 2005 (UTC)

There should also be the opportunity for plenty of expansion based on the NeXTSTEP-based Mac OS X package format. —Miles←☎ 20:56, May 16, 2005 (UTC)

Uninstall?

Please mention if there is a way to uninstall packages installed with Installer. Or mention if there isn't a way. --Spoon! 18:01, 21 September 2007 (UTC)

Also would be useful to know when a .dmg installer file can be discarded. I've just installed 109 Mb of software, using a .dmg file that's 30 or so Mb. I'd like to ditch this 30 Mb if possible. In the past, I've discarded a .dmg file and then found the software complaining that it couldn't work without it. Lemastre 5/25/08 —Preceding comment was added at 12:03, 25 May 2008 (UTC)

That should not happen. First, what is a .dmg installer file? Installer files are .pkg or .mpkg, not disk images. And an "installer" should put all the software and its components on the install disk. —[semicolons]— 10:49, 24 June 2008 (UTC)

Installer is too intrusive and takes too many clicks?

Is it just me who thinks that the Apple Installer should just "get on with it" instead of waiting for the user to click Continue 5 or more times, and select a volume? How about a way to state your main volume, and use this going forwards? Then installers could be totally automatic. Klf uk (talk) 10:41, 19 April 2009 (UTC)

Bundles and packages

As Apple's "About Bundles" section of the Bundle Programming Guide says:

Although bundles and packages are sometimes referred to interchangeably, they actually represent very distinct concepts:

• A package is any directory that the Finder presents to the user as if it were a single file.
• A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.

As the legacy version of Apple's software delivery guide says:

An installation package (also known as a package) is a file package (a directory that appears in the Finder as a single file) created using the PackageMaker application (/Developer/Applications/Utilities). Packages contain a product or product component—the package’s payload—to be installed on a computer, and install configuration information that determines where and how the product is installed.

Note: Application executables are usually enclosed in a bundle: a structured directory hierarchy that contains resources needed by the application, such as images and localized strings. Because these bundles are normally file packages, the term application package refers to an application bundle that the Finder displays as a single file. However, in this document the term package refers to an installation package, not an application package. For detailed information on Mac OS X bundles, see Bundle Programming Guide.

And, as the illustrations in the MacTech article "The Flat Package" indicate, a non-flat installation package has a structure similar to an OS X bundle, it doesn't "hold both executable code and the resources used by that code". It has a similar directory structure to a bundle (Contents directory, Resources directory, Info.plist file, but it's not a bundle. Guy Harris (talk) 06:04, 22 March 2015 (UTC)

Your changes to my text you took from Package (OS X) make no sense. To quote your change "installer packages were implemented as OS X packages", theses two terms are the same thing, which is why I had my information in the Package (OS X) article to begin with, before you moved it to Installer (OS X). There is no difference in "installer package" and a "OS X package", the only difference in packages were with the implementation, they used different structures in different versions of OS X but the biggest difference is that of the use of a directory for a container vs the Xar container. Your last changes to my text should be reverted and that text should be moved back to Package (OS X), otherwise you should just merge the two articles since you're writing about "installer packages" which are in fact the same as Package (OS X).Offnfopt (talk) 22:33, 22 March 2015 (UTC)

""installer packages were implemented as OS X packages", theses two terms are the same thing" Wrong.

Installer packages are the .pkg things that show up in the Finder as open boxes with a clear yellow thing coming out of them. They can be implemented as a single xar file or as a directory tree; the latter, but not the former, are OS X packages. So not all installer packages are OS X packages.

OS X packages are directory trees that are treated as single objects by the Finder (except for frameworks, which, for some reason, show up as directories in the Finder). They can be bundles (application, framework, loadable, or kext), .lproj bundles, document packages, etc.. So not all OS X packages are installer packages.

Therefore, installer packages and OS X packages are two separate categories, with some but not all entities belonging to both categories. Guy Harris (talk) 23:15, 22 March 2015 (UTC)

Again, they are both considered a package, pre-appending the term "package" with "installer" or "OS X" does not change anything. You are trying to create a separation in the subject matter when the subject matter is in fact the same. They both have the same function, the only difference is their implementation which was dependent on the OS X version. What you are deeming a "installer package" is a "OS X package". The problem with the Package (OS X) page is the information there (which you wrote) only talks about one specific implementation of a OS X package, when in fact there are multiple implementation of a OS X package. You have effectively taken these pages and come to the mind set that you're right about everything and everyone else is wrong so you're going to warp their text to try to fit your misguiding understanding of what a package is. Since you think you know everything about packages, you should actually write your own words and actually explain the subject matter instead of taking others words and completely twisting them to the point where they make no sense. This is meant to be a encyclopedia, where someone could come to this page and get a good understanding of the subject matter, due to your misguided policing. Again, my text that you moved here from Package (OS X) should be listed in Package (OS X) not here and this article need a lot of improvement. I would improve the article but it is obvious you would revert every change because of your misguiding understanding of the subject matter.Offnfopt (talk) 00:56, 23 March 2015 (UTC)

Apple use the term "package" for at least two things: the "package" that is "any directory that the Finder presents to the user as if it were a single file", as described by the "About Bundles" section in the Bundle Programming Guide, and the "package" that is "a file package (a directory that appears in the Finder as a single file) created using the PackageMaker application (/Developer/Applications/Utilities).", as described by the "Managed Installs" in the Software Delivery Legacy Guide.

Most Mac users may be familiar with the latter type of package, but may not be familiar with the use of "package" to describe the former type of package, so they might think that "package", in the OS X context, refers only to installer packages (the latter type). However, at least some developers will be familar with both types.

The Wikipedia should discuss the two types of package separately, in order to be correct and not mislead readers.

The Software Delivery Legacy Guide doesn't discuss the flat package format, so when it says that an installer package is "a file package (a directory that appears in the Finder as a single file) created using the PackageMaker application (/Developer/Applications/Utilities).", it doesn't cover the flat package format. A flat installer package is an xar archive of a directory tree "containing either a metapackage or a single package", according to Flat Package Format - The missing documentation; "The Flat Package" gives more details on the directory tree inside the archive. Within the file system, a flat package is a single file, so it's not a "directory that the Finder presents to the user as if it were a single file" and thus not a package in the sense of Package (OS X), although if it were to be unpacked into a directory ending with .pkg, the Finder might treat the resulting directory as a package in that sense - but I don't know whether the Installer would handle it or not. (I tried it with Wireshark's flat package, calling the resulting directory Wireshark.pkg; the Finder showed it with the package icon, but if I double-click on it on my Mountain Lion machine, the Installer complains "The operation couldn’t be completed. (com.apple.installer.pagecontroller error -1.)") Guy Harris (talk) 18:12, 23 March 2015 (UTC)

Regarding your comment "it doesn't hold both executable code and the resources used by that code" re-read the articles in question and you'll see that is incorrect, this information is stored in the pax archives that are included in the bundle.Offnfopt (talk) 22:45, 22 March 2015 (UTC)

Installer packages may happen to include, in the pax archives, executable code, because that's what you're installing, but the structure is different - there is, for example, no MacOS subdirectory of Contents with an application executable image or run-time-loadable image or kernel loadable module image in it, so it's not an application or loadable or kext bundle, and there isn't a Versions directory with subdirectories containing dynamic library images, so it's not a framework bundle. The directory structure of a non-xar installer package, or the archived directory structure in an xar installer package, might happen to contain Contents or Resources directories at the top level, along the lines of what appears in an OS X bundle, but that's not sufficient to say that they're bundles; Apple's definition of "bundle" in "About Bundles" in the Bundle Programming Guide is more limited, and they say that "Although document formats can leverage the bundle structure to organize their contents, documents are generally not considered bundles in the purest sense. A document that is implemented as a directory and treated as an opaque type is considered to be a document package, regardless of its internal format.", so they may view installer packages as "document packages" but not bundles. Guy Harris (talk) 23:40, 22 March 2015 (UTC)