Hi Art,
Nice to hear from you.
Comments inline:
Art Peck wrote:
Bob -
So why don't we have utinstall figure out the path to all the bits we need and
log them in a sort of header script that other scripts can source? I realize
this will not overcome all the distro variations, but it seems like it would go
a long way.
That's an interesting suggestion, but I think creating symlinks would be
a better solution, so that C programs could benefit also.
The only problem would come on a system that had SRSS installed and then
upgraded an external component that changed its location (e.g. GDM has
done this before in various distros).
I'll think about doing this in our activation framework. I'd like to get
to a model where you can upgrade the underlying platform and then invoke
our activation framework to recreate our runtime environment integration
layer. Activation is a very quick operation (it's automatic currently
during the post-utinstall reboot, but can also be invoked manually).
The problem with Ubuntu and utgdmconfigpath and the approach you suggest
is simply:
"Where all do you check for something"?
We keep expanding the locations utgdmconfigpath checks. But those
rascally distros keep outsmarting us by finding someplace new to put
stuff. So we expand the check to cover the new location. It feels like
the old "Spy vs Spy" comic from Mad magazine :)
Actually given that we now know that this version of Ubuntu is using the
completely-rewritten GDM 2.28, we know the main problem the fact that
the rewrite doesn't have gdmdynamic any more, or for that matter *any*
way to dynamically create a new display. There's no solution to this
that can be offered within SRSS.
As Joerg said, Sun engineers have been contributing to the GDM source
base to recreate a method for dynamic display management, but that will
take time to integrate into the main GDM trunk (obviously we'll branch
temporarily if necessary in OpenSolaris until the trunk catches up), and
it won't be backwards compatible so SRSS will also have to change to
integrate the new GDM. That'll happen in our next release. The simplest
workaround for intrepid adventurers will be to create a wrapper, call it
"gdmdynamic", and recreate the old interface while wrapping the new one,
then install the gdmdynamic wrapper in the location where the old GDM
provided it. That's what OpenSolaris plans to do when integrating the
new GDM, in order to provide a smooth transition period while SRSS
adapts to the new native interface. Particularly since the new interface
keeps getting revised so SRSS has nothing stable we can count on yet (at
least not so far, maybe this has finally changed). It's worth noting
that this interface instability/change isn't due to Sun's engineers, but
rather the GDM community owners who didn't like the old interface. There
will also be some changes required for configuring the new GDM, which
should be applied to /opt/SUNWut/lib/utctl.d/features/utgdmconfigctl.
-Bob
Sorry for hijacking this thread, but it seemed sort of relevant.
Art
--
Art Peck
Managing Partner & Principal Consultant
A rthur H. Peck & Associates, LLC
Cell: 904-614-7902 Skype: 904-638-5056
Email: [email protected] Website: http://artpeck.net
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
