site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On May 18, 2005, at 3:18 PM, Peter Bierman wrote: -pmb At 12:04 AM -0400 5/18/05, Joe Ridge wrote: On May 14, 2005, at 5:53 PM, Peter Bierman wrote: At 1:58 AM -0400 5/14/05, Joe Ridge wrote: Why can't the iTunes group make an installer that is not broken? -pmb On May 14, 2005, at 1:58 AM, Joe Ridge wrote: Why can't the iTunes group make an installer that is not broken? _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... I'm not sure why $USER isn't set. The main place I see this come up is in the boot context. I have a startupItem that calls a perl script that calls the softwareupdate command line tool, in back ticks. I'm really not doing anything to the environment. Which I guess means that the SystemStarter is not doing anything to setup the environment for the StartupItems. In addition to $USER there is respectable number of other environmental variables that it is easy to label as common. With no clear API, I don't know which I have to code in, I just have to wait for the macs I support to break and then go debug it, and add that to the list of Variables that I have seen used, and which MIGHT be used again. Right now I'm gluing softwareupdate to SystemStarter and because none of the requirements are documented I have no leverage to get a solution that will be a long term fix. Also I am not sure why su $USER -c is even really being used. As far as I know, $USER is an exceptionally common environment variable used by all sorts of code throughout the system. As you point out, there is no documented API or environment for these scripts. Apple tests them in the environment created by the Software Update app and the Install framework. If you replace either of those components, the burden of matching the prerequisites moves to you. But all that aside, I'm left wondering why $USER isn't already set correctly in your environment. So it's not about what I can and cannot do. It's about adherence to the API. The requirement of $USER, is undocumented, and sure once I hit the bug, I can code in a bug fix to my code, but then another Apple group can make another assumption about the environment that I will have to hit debug and code in. And then it's a whole monolithic mess. Using $USER is like using part of an undocumented API, If I go and change the implementation to one that strictly adheres to the published API, and does not have the undocumented feature, then the problem is with the code that used the undocumented feature not the code that didn't implement it. Now it would be perfectly OK for the group responsible for the installer program to publish a list of environmental variable that were safe to use, and a list of environmental variables that anything that calls installer must provide. Then in my case the people responsible for softwareupdate would then have to ensure that either they ensure those variables are set or publish the environmental requirements and as requirements for softwareupdate. And if that happened, I would happily vouch safe my environment against the published requirements that I was given, by the program I was using. The preinstall and preupgrade scripts both contain a bug that prevents execution from an automated environment. They use "su ${USER} -c ...." to execute a command, but if the installer is being run through cron or as a startup item the ${USER} variable is not defined. and the su doesn't execute the command and instead becomes a shell that will never exit. Since you're creating the crontab or startup item in this case, why can't your code/script make sure that $USER is defined? And in both cases, I don't know why $USER wouldn't be defined already. 'man 5 crontab' suggests that $USER is one of the environment vars set by cron. The preinstall and preupgrade scripts both contain a bug that prevents execution from an automated environment. They use "su ${USER} -c ...." to execute a command, but if the installer is being run through cron or as a startup item the ${USER} variable is not defined. and the su doesn't execute the command and instead becomes a shell that will never exit. The worst part about this is that I reported the same exact bug with the 4.7 installer. Maybe if they aren't going to write good packages we should petition the people who write the installer to populate the environment before they hand off to the packages scripts. But I'm not bitter. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (<mailto:Installer- dev@lists.apple.com>Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: <http://lists.apple.com/mailman/options/installer-dev/ridge% 40umiacs.umd.edu>http://lists.apple.com/mailman/options/ installer-dev/ridge%40umiacs.umd.edu This email sent to <mailto:ridge@umiacs.umd.edu>ridge@umiacs.umd.edu _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/bierman% 40apple.com This email sent to bierman@apple.com This email sent to site_archiver@lists.apple.com