Re: updaters
Re: updaters
- Subject: Re: updaters
- From: Dodger <email@hidden>
- Date: Wed, 18 Feb 2009 16:21:22 -0800
Yup yup.
I'd also like them to fix that preflight/preinstal absolute path
problem. Setting a script invisible in the root of the DMG is a hack
at best, but it's the only think I can think to do to.
2009/2/18 Karl Kuehn <email@hidden>:
> On Feb 18, 2009, at 3:01 PM, Dodger wrote:
>
>>> I've been thinking about this. Is there a way Apple could disallow these
>>> arbitrary installer scripts and still support the scenarios that seem to
>>> require them? Perhaps this warrants a separate thread.
>>
>> If you mean disallow any external scripts, well, there's a reason
>> they're allowed: to allow for things they haven't foreseen. I know my
>> problem would be very unlikely to be handled in the packagemaker app,
>> for instance (i.e. applying a morph target to an Alias Wavefront Maya
>> object file and saving out the results). If Apple foresaw that need,
>> they probably *still* wouldn't include the possibility because it
>> would be so rare.
>
> I agree completely that there is no way that Apple could get rid
> scripts from installers. I think that the better way of making both the
> installer-writers and the system-admins happy would be to have a way for
> installer script to tell the installer program that they had touched
> specific files so that the installer could then communicate that
> appropriately (through .bom's, etc). And vitally important: document that as
> an important thing.
>
> What I would want in the perfect installer program has been in my
> mind much recently, and since nobody asked here are a few things that I
> would want:
>
> - Ability to sandbox/chroot the installer scripts so that it only used and
> wrote to the target volume
>
> - The same as above, but for the javascript sections of the installer
>
> - An explicit mechanism for licensing/registration systems. I am thinking
> about something like a plugin system, but with the ability to pass the
> licensing/registration information from the command line for command-line
> installs. It would also allow for a GUI that would provide the information
> to the Plugin the same way. I don't want Apple to mess around with trying to
> do this themselves, but rather to provide a consistent interface for
> package-developers to do so.
>
> - Better documentation and examples of how to write all of the javascript
> components now allowed (documentation on this is really hard to find)
>
> - Apple emphasizing to installer writers (both internal and external) that
> their installers will not always be used by consumers on a single machine
> that they are logged into. (InstaDMG has become the lens I view this
> thorough)
>
> And on the really-out-there field:
>
> - Redo the conversion to XAR and this time don't just wrap a CPIO inside a
> XAR but rather extend XAR to handle all of the cases the CPIO handles. With
> some careful work this would allow for tools like Radmind to work directly
> with .pkg's rather than replace them.
>
> --
> Karl Kuehn
> 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
>
--
Dodger
_______________________________________________
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