February 2006 - Installer-dev

Installer background - custom size
by Stanfield, Albert R 23 Feb '06

23 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcY4GgcuOlzB2iQHQRCIvRzQPhpw9Q== Thread-topic: Installer background - custom size _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

How to find and update a bundle on all local volumes but skip if it is not found
by Dary Mihova 22 Feb '06

22 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks in advance, Dary Mihova _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I am stuck with the following problem and I don't know how to fix it. I need to make an installer that finds and updates only few resources in a specific version of a bundle. If this version of the bundle is not found the installer should skip this bundle and install nothing. The Installer needs to search for the bundle on all local volumes before giving up. Using TokenDefinition.plist and the keys IFPkgComponents and IFPkgPathMappings I created an installer that finds the proper version of the bundle and updates if it is on the selected by the user volume. The problem is that it won't find it, if the bundle is on a different volume. The other problem that I can't solve is the behavior when the bundle is not found. The installer installs the resources on the default path. I am thinking on cleaning the installed this way resources with a postflight script but I wonder if there is an easy way to tell the Installer to skip the installation. Actually the most serious problem to me is how to tell the installer to search on all local machine volumes. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Relocatable packaging, other drives and authentication
by Christopher Ryan 22 Feb '06

22 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Nathan, I've been playing around with the InstallerDist2.dmg files to see what can be done with .dist files. One limitation of the .dist appears to be that you cannot set your install point to be one volume, but have a choice with a different custom location point to a different volume. I can imagine that a user with sufficiently small OS drive space may decide to install the fonts into /Library/Fonts, but have the main application on an alternative partition, e.g. /Volumes/Data. Is this the case, or am I missing something? Chris Thanks in advance, Nathan ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/ryanc%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… One of the things we've been playing around in our designs is the following: * Default installation "domain" is the local domain, s.t. the main applications go into /Applications and the fonts go into /Library/Fonts[/Microsoft] * Alternate installation "domain" of the user domain, s.t. the main applications go into ~/Applications and the fonts go into ~/Library/Fonts[/Microsoft] - this is specifically to target users who have a copy of Office they want to run on a lab machine where they don't have admin authority. * Alternate installation "domain" of the network domain, s.t. the main applications go into /Network/Applications and the fonts go into /Network/Library/Fonts[/Microsoft]. * Custom location for the applications, perhaps also the fonts; probably still within the idea of the domain, just so that the permissions can be set accordingly. There is currently no "good" support for this "domain" like install you are requesting. The good news is if you set up your install correctly and the user chooses to install their package in their home directory (by selecting their root volume and choosing their home directory folder) then the Installer will correctly install things as the user rather then as root:admin and will not request authentication. Unfortunately this sort of thing is hard for the user to figure out, so I don't suggest going down this route. Yes, this is possible, although there are some limitations. You can allow the user to select the location of different choices in a distribution. However, when you let the user select a new location, there is no way to select "domains" only folders, so the user could easily install the fonts in a location you do not want. You are better off always installing into /Library/Fonts, /Applications/, etc, and having people that know better move things to other domains (/Network and/or ~/). Another apparent limitation of the package system (though I haven't tried it to make sure), is that in order to support the application's default installation of into /Applications, I'd need to make the permissions be root:admin 1775. However, if I'm in the "user" case, where the user isn't an admin and doesn't plan on installing the application for all users, I'd not be able to make the permissions be root:admin even if I wanted to (which I don't, I'd rather it just be the user's uid and gid). Furthermore, it seems like it's just a static setting that a package requires admin authentication or not. Is this the case, or am I missing something? See above, if the user installs in their home directory (this is a special case) it will not authenticate and install the package as the user. This email sent to ryanc(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

RE: "Repairing" an installation
by Nathan Herring 22 Feb '06

22 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcY2nl0VOOHmWs7STd+cdlpEk3meFAAuD9xQ Thread-topic: "Repairing" an installation Well, if the application can tell if their preferences are damaged, it's already got code to try and clean them up. The problem is when it cannot tell (subtle corruption) or when they're not really damaged so much as there is some considered-valid preference combination that causes grief on a user's machine. At that point, being able to get back to a "clean" state to see whether the problem recurs is a useful tactic for support. If it does recur, then there is probably something else odd with the machine setup. If not, then perhaps there's a bug, or there is some interaction between machine setup and some preference choice. In these cases, it is worth having some manual mechanism to allow the user to get back to a "clean" state. -nh -----Original Message----- From: Stéphane Sudre [mailto:ssudre2@wanadoo.fr] Sent: Monday, February 20, 2006 1:05 PM To: Nathan Herring Cc: installer-dev(a)lists.apple.com Subject: Re: "Repairing" an installation Frankly, I don't see myself going to the Installer to repair the preferences file of a software. It looks more intuitive to have the software itself deal with the "corrupted" preferences. If it (the software) can't automatically repair them, then an alert can be displayed to inform the user about the situation and that the preferences are going to be reseted to the default/factory settings. Regarding the "support" request to clean the preferences, considering the solution above is implemented (so that you can be sure that the application can be launched), you could use a key combination to change the Preferences... menu item in the application menu to Reset Preferences... (something like Control + alt). When the user selects the Menu Item, a dialog asks him/her to confirm the reset of the preferences. Problem with this solution: you have to deal with the reset of preferences within the application. My $0.02 before tax. On lundi, février 20, 2006, at 09:32 PM, Nathan Herring wrote: > AFAICT, the Apple installer doesn't really have a repair operation - > you > can elect to install over a previous installation, though you can add > checks to enforce that you don't downgrade. A feature that our product > support often requests is also a mechanism to clean out the preference > files (usually accomplished by running our Remove Office application > and > choosing only preferences files) to make sure that some odd setting (or > corrupted preference data) isn't causing a customer's problem. > > We could clearly leave things as they are; PSS can walk customers > through the steps to remove their preferences if necessary. However, > does Apple suggest a way to handle these kinds of repair operations? > Should it be separate UI, like a setup assistant? (a Repair assistant?) > Or is this something that would get into the installer itself, and if > so, should we just wait for the Apple installer to add it? > > Thanks in advance, > Nathan > > ---- > Nathan Herring > MacBU SDE/Development > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/installer-dev/ > ssudre2%40wanadoo.fr > > This email sent to ssudre2(a)wanadoo.fr > ----------------------------------------------------------------------- > ---------------- > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus > mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Relocatable packaging, other drives and authentication
by Nathan Herring 22 Feb '06

22 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcY3VhWgBZFB1PQDQLiC60L/87m9fw== Thread-topic: Relocatable packaging, other drives and authentication I've been playing around with the InstallerDist2.dmg files to see what can be done with .dist files. One of the things we've been playing around in our designs is the following: * Default installation "domain" is the local domain, s.t. the main applications go into /Applications and the fonts go into /Library/Fonts[/Microsoft] * Alternate installation "domain" of the user domain, s.t. the main applications go into ~/Applications and the fonts go into ~/Library/Fonts[/Microsoft] - this is specifically to target users who have a copy of Office they want to run on a lab machine where they don't have admin authority. * Alternate installation "domain" of the network domain, s.t. the main applications go into /Network/Applications and the fonts go into /Network/Library/Fonts[/Microsoft]. * Custom location for the applications, perhaps also the fonts; probably still within the idea of the domain, just so that the permissions can be set accordingly. One limitation of the .dist appears to be that you cannot set your install point to be one volume, but have a choice with a different custom location point to a different volume. I can imagine that a user with sufficiently small OS drive space may decide to install the fonts into /Library/Fonts, but have the main application on an alternative partition, e.g. /Volumes/Data. Is this the case, or am I missing something? Another apparent limitation of the package system (though I haven't tried it to make sure), is that in order to support the application's default installation of into /Applications, I'd need to make the permissions be root:admin 1775. However, if I'm in the "user" case, where the user isn't an admin and doesn't plan on installing the application for all users, I'd not be able to make the permissions be root:admin even if I wanted to (which I don't, I'd rather it just be the user's uid and gid). Furthermore, it seems like it's just a static setting that a package requires admin authentication or not. Is this the case, or am I missing something? Thanks in advance, Nathan ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Automating PackageMaker CLI with Preserve Resource Forks option
by Nathan Herring 20 Feb '06

20 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcYzWI7UShzayMXlRTunifKqdxSCtQDDPJQQ Thread-topic: Automating PackageMaker CLI with Preserve Resource Forks option _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: "Repairing" an installation
by Stéphane Sudre 20 Feb '06

20 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com My $0.02 before tax. On lundi, février 20, 2006, at 09:32 PM, Nathan Herring wrote: We could clearly leave things as they are; PSS can walk customers through the steps to remove their preferences if necessary. However, does Apple suggest a way to handle these kinds of repair operations? Should it be separate UI, like a setup assistant? (a Repair assistant?) Or is this something that would get into the installer itself, and if so, should we just wait for the Apple installer to add it? Thanks in advance, Nathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… Frankly, I don't see myself going to the Installer to repair the preferences file of a software. It looks more intuitive to have the software itself deal with the "corrupted" preferences. If it (the software) can't automatically repair them, then an alert can be displayed to inform the user about the situation and that the preferences are going to be reseted to the default/factory settings. Regarding the "support" request to clean the preferences, considering the solution above is implemented (so that you can be sure that the application can be launched), you could use a key combination to change the Preferences… menu item in the application menu to Reset Preferences… (something like Control + alt). When the user selects the Menu Item, a dialog asks him/her to confirm the reset of the preferences. Problem with this solution: you have to deal with the reset of preferences within the application. AFAICT, the Apple installer doesn't really have a repair operation - you can elect to install over a previous installation, though you can add checks to enforce that you don't downgrade. A feature that our product support often requests is also a mechanism to clean out the preference files (usually accomplished by running our Remove Office application and choosing only preferences files) to make sure that some odd setting (or corrupted preference data) isn't causing a customer's problem. ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/ ssudre2%40wanadoo.fr This email sent to ssudre2(a)wanadoo.fr ----------------------------------------------------------------------- ---------------- Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. This email sent to site_archiver(a)lists.apple.com

1 0

"Repairing" an installation
by Nathan Herring 20 Feb '06

20 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcY2XMmWHMupJkt/QjWbLoahGjzQMQ== Thread-topic: "Repairing" an installation AFAICT, the Apple installer doesn't really have a repair operation - you can elect to install over a previous installation, though you can add checks to enforce that you don't downgrade. A feature that our product support often requests is also a mechanism to clean out the preference files (usually accomplished by running our Remove Office application and choosing only preferences files) to make sure that some odd setting (or corrupted preference data) isn't causing a customer's problem. We could clearly leave things as they are; PSS can walk customers through the steps to remove their preferences if necessary. However, does Apple suggest a way to handle these kinds of repair operations? Should it be separate UI, like a setup assistant? (a Repair assistant?) Or is this something that would get into the installer itself, and if so, should we just wait for the Apple installer to add it? Thanks in advance, Nathan ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Installer vs. Setup Assistants vs. Uninstallers
by Nathan Herring 20 Feb '06

20 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcY2Wr2EjQqw+SzhRL2KG8ZxOS+e5Q== Thread-topic: Installer vs. Setup Assistants vs. Uninstallers In the current shipping version of Microsoft Office 2004, our Setup Assistant application is a combination of what Apple's documents would describe as an installer and a setup assistant (http://developer.apple.com/documentation/UserExperience/Conceptual/OSXH IGuidelines/XHIGInstallationsUpdates/chapter_9_section_4.html). Is the Apple separation of these two things specifically desired and, if so, why? One of the differences between the two is that an Installer generally just installs the product (though it does accomplish the ancillary task of license acceptance), and it leaves the setup assistant tasks to the first time you launch the program. Our current product is a mix of both: The setup assistant, run separately, takes care of setup operations and accomplishes the install. If you drag-and-drop, then the setup assistant is run, though it bypasses several of the installation-specific tasks. >From the HIG and from viewing the installer, the UI for both installers and setup assistants are incredibly similar: bevel button lists on the left, work panes on the right. Is there any reason not to use the installer's custom installer pane technology to implement a setup assistant? I'm asking these questions from a HIG standpoint... what's the Apple take on how the workflow of installing/setting up an application should work. Also, whereas the HIG suggests that you provide an uninstaller, the Apple installer currently doesn't have an uninstall function. In our case, we have uninstaller that uninstalls older versions as well. Where would Apple suggest it be placed in the order of operations? (i.e., should we and when should we offer the user the option to remove older versions of the product?) Thanks in advance, Nathan ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: /Library/Receipts, installing a pkg without admin authorization?
by Fazan 17 Feb '06

17 Feb '06

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kP2s+S9io3Nlutga64U45cY3FPCtXVY/n3umLl6S0Qkq8RgYw7I4Zu7bEx8nzOz74K5y1fWMINPdEeNhk+8sP3i7uRh6rAg3r4A26nLfAYf0OGSW4Vd5b/D/YiSp06qUkmAxVllkePAEKg/WoV+U0CftzndfvJe9iO1IpRTsUTI= ; --- Peter Bierman <bierman(a)apple.com> wrote: > At 2:56 PM -0800 2/17/06, Fazan wrote: > > I am creating my own package and currently I > don't > >do anything in the install that requires admin > >authorization. Therefore, I am setting > >IFPkgFlagAuthorizationAction to NoAuthorization. > When > >I install the package as an ordinary user, it > appears > >to install correctly, but the Installer fails with > an > >error message: "There were errors installing the > >software". When I viewed the installer log, I see > an > >error message about how it is trying to move an > >existing receipt /private/tmp/.<my app name> to > >/Library/Receipts/<my app name>. The permissions > of > >/Library/Receipts are rwxrwxr-x (owned by root), > and > >since I'm not logged in as an administrator, it > makes > >sense that it fails. > > > > Does every installer package created with > >PackageMaker attempt to write to /Library/Receipts? > >If so, does this mean that only administrators can > >install packages? Or is there something wrong with > >the permissions on my /Library/Receipts directory? > > > It's not PackageMaker, but any OS X installer > package at all. This is > a side effect of us tightening the permissions on > /Library/Receipts/ > > This is usually not a problem, because there's very > little software > that can be installed somewhere other than in the > home directory > without admin privileges. If your NoAuthorization > package is > installed in a homedir, then the receipt should end > up in ~/L/R/, > which is not as restrictive. > > Where are you installing your software that's not a > home dir but > still doesn't require authorization? > > -pmb > I am installing the app to a subdirectory within my home directory. It seems like in this case, installer should place the receipt in ~/Library/Receipts/ as you indicated? Are there other installer properties I need to configure for this to work? Fazan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0