Hi Moinak,
Moinak Ghosh wrote:
> On Sun, Jun 15, 2008 at 10:59 AM, Laszlo (Laca) Peter
> <Laszlo.Peter at sun.com> wrote:
>
>> On Sat, 2008-06-14 at 14:08 +0100, Peter Tribble wrote:
>>
>>> On Fri, Jun 6, 2008 at 8:55 PM, Erwann Chenede <Erwann.Chenede at sun.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> As described by Laca in April [1] upgrading GNOME packages with IPS is
>>>> problematic as various caches need to be updated.
>>>>
>>>> Currently it is handled by postinstall scripts. As this functionality isn't
>>>> (intentionally) provided by IPS. The creation of SMF services to update
>>>> these
>>>> caches is needed.
>>>>
>>> Looking at consequences like this make you realize just why you need some
>>> level of "scripting" integrated into packaging :-(
>>>
>>> Why 6 services? The number of services is exploding, leading to performance
>>> and
>>> manageability issues. Is there an intrinsic reason why these have to be
>>> separate
>>> rather than just a single 'update-caches' service?
>>>
>> Well, they do very different things and should be triggered by the
>> installation of different kind of files.
>>
>> We considered a generic service, something like postrun, but decided
>> that letting smf manage the dependencies, etc is more robust and
>> having one service per cache makes it a lot easier to diagnose issues.
>>
>
> IMHO this sets a questionable precedent. Every package or package
> group that cannot do without postinstall will tend to supply it's own
> service. Do want to have a proliferation of postinstall handling services ?
> Wasn't the postrun service and future action identified for packages that
> simply cannot do without a postinstall ?
>
Afaik we were told the services were the way to go. Beside the IPS
actions are not implemented so we needed
an interim solution to avoid breaking gnome 2.22 when it become
available as part of build 92.
> Looks like the find commands will have negative impact on startup
> performance. The impact will be especially severe for Indiana LiveCD.
>
Afaik the LiveCD takes an image of the file system so these services
don't need to be present on the LiveCD also
during the construction of the LiveCD one controls what's on the LiveCD
so the caches can be generated statically
before hand by the distro constructor I believe.
> A better approach would be to have some for of indication to the scripts
> that some schema/cache is dirty
IPS actions when available could do that. Once it is available we'll be
able to make these services more clever.
> and the update needs to be run rather
> than blindly doing finds.
[...]
> Better still would be to have the services disabled
> by default and dependency from GDM being optional_all. A refresh of the
> GNOME packages should trigger the services to execute and disable
> themselves upon successful completion.
>
Yes this is an interesting idea but without IPS actions I don't see how
to achieve this.
> [OT] Can't help but mention that this is a bigger GNOME problem that it
> needs so much of postinstall processing. I had packaged complete KDE
> 3.5.x for BeleniX and not a single package required any kind of scripting.
>
Hmm, interesting, howdid KDE go around this problem of updating caches
that span multiple packages without
post install scripting ? Is this done at application startup ?
Thanks,
Erwann
--
Erwann Ch?ned?,
Desktop Group, Sun Microsystems, Grenoble
