|
The files only get copied to the home
folder of the user who is installing the samples. I certainly
didn't want every user to get the samples but I will double check
that that is not happening. Thanks for the heads up on that.
On 04/09/2013 16:24, Greg Neagle wrote:
And in the "multiple user accounts on one machine" scenario, I
_don't_ think the right approach is to just copy your files to
every single home folder found on the machine. That makes the
assumption that every user on the machine _wants_ to use your
software.
As suggested by others, a better approach is to install the
data files somewhere globally readable; if read/write copies are
needed, copy them/create them in the user's home on first launch
of your software if they are missing.
This approach covers all the scenarios.
-Greg
On Sep 4, 2013, at 8:17 AM, Steve Stockman < email@hidden>
wrote:
Greg gave some examples of why the installer might
not find a user's home directory, such as network
users or the possibility of a machine being
pre-configured. To that I would add
1. Users whose accounts are created on the machine
after the software was installed (really a superset of
the preconfiguration scenario).
2. In earlier Mac OS X versions, if a FileVaulted
user is not currently logged in, his entire home
directory consists of a single encrypted disk image.
––––––––––––––––––––––––––––––––––
Steve
Stockman
Software
Architect/Technical Director
Consumer
Products - Macintosh
Symantec
Corporation
www.symantec.com
––––––––––––––––––––––––––––––––––
<4D7338AD-DC3B-4D86-BC21-D85E9B58878F[2].png>
From: James
Pritchard < email@hidden>
Date:
Wednesday, September 4, 2013 10:08 AM
To:
installer-Dev mailing-list < email@hidden>
Subject: Fwd:
Re: Installing to users Home folder using Packages
-------- Original Message --------
On 04/09/2013 15:48, Steve Stockman wrote:
> I don't think software versus data is Greg's point here. The point is that
> your software requires certain files to exist within a user's home
> directory, which might be unavailable or even non-existent at install time.
The software doesn't require the samples. If anything the samples
require the software and I think we did have a check in PackageMaker for
this so I will look into whether this is possible with Packages.
>
> If the files are never to be modified after installation, rather than have
> them in a home directory, just keep them within the application bundle
> itself or somewhere within "/Library/Application Support".
The files can be modified.
> If you are installing initial/default forms of files that may be modified
> as the software runs, the normal way to accomplish this is:
> 1. Install the initial or default form of the data in a known location,
> such as within your application bundle or somewhere within
> "/Library/Application Support". If we are talking about multiple files, it
> would probably be handy to install a single tar or zip archive.
> 2. When your app or agent launches, it checks the current user's home
> directory for the presence of those files, and copies them there if they
> do not already exist. This can either be done immediately at startup, or
> lazily as the files are actually needed.
This is something we've done in the past with our Windows software but
have moved away from as a solution.
> Those steps accomplish two things:
> 1. It provides for users whose home directories would not be found by the
> installer.
Is it common for the users home directory not to be found by the
installer? Would my postflight script I previously employed suffer
similar problems and how would the application find it when the
installer and the script can't?
>
> 2. It prevents a subsequent version of your installer from overwriting
> files that have already been modified within a home directory without
> having to go through any complex version checking.
I think I made sure my postflight script did not overwrite modified
files but I will certainly check that the installer is not doing this
and if it is then this is potentially not an option.
Steve Stockman
Software Architect/Technical Director
Consumer Products - Macintosh
Symantec Corporation
www.symantec.com <http://www.symantec.com/>
-----Original Message-----
From: James Pritchard <email@hidden>
Date: Wednesday, September 4, 2013 9:28 AM
To: Greg Neagle <email@hidden>
Cc: "email@hidden" <email@hidden>
Subject: Re: Installing to users Home folder using Packages
>> It's not software we install to the users home folder but additional
>> sample files.
>>
>> On 04/09/2013 15:21, Greg Neagle wrote:
>>> Why do you need to do this?
>>>
>>> I would not want to use/support your software in an enterprise
>>> environment where:
>>>
>>> 1) There may be multiple user accounts on a machine
>>> 2) User accounts might come from a directory service and therefore have
>>> no "footprint" on a machine when your software is installed.
>>> 3) The user installing your software might be a site administrator, and
>>> not the user who will be using your software.
>>> 4) The software might be installed by an automated process and there
>>> might be no user logged in at all at the time of install.
>>> 5) A machine might be set up and configured _before_ the main user's
>>> account is created; the main user's account may not even exist at the
>>> time of the installation of your software.
>>>
>>> Software should not _require_ the installation of anything in a user's
>>> home directory.
>>>
>>> -Greg
>>>
>>> On Sep 4, 2013, at 3:32 AM, James Pritchard <email@hidden>
>>> wrote:
>>>
>>>> Up until now we've been using PackageMaker to put together our
>>>> installs but looking to make a change to use Packages for our next
>>>> software release.
>>>>
>>>> An issue we had using PackageMaker was with installing to the users
>>>> Home folder. Our solution was to install to the /tmp folder and then
>>>> copy the files across in a post flight script. Can anyone tell me if
>>>> there a way of installing to the Home folder in Packages, or should I
>>>> just carry on using my existing post flight script.
>>>>
>>>> Thanks,
>>>> James
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Installer-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> eyanimation.com
>>>>
>>>> This email sent to email@hidden
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Installer-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> antec.com
>>
>> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be
ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|