Alan Coopersmith wrote:
> Kyle McDonald wrote:
>> Should SUNWxwkey be in some Xwindows cluster? it (like SUNWxwpl) is
>> left to be installed by itself.
>
> That's another one of those packages that looks like X but comes from
> another
> team. It's only useful on a very small number of machines (SPARC
> machines
> with PS/2 keyboards, not USB or SPARC keyboards - which is mainly the
> SPARC
> laptops and systems built out of the SPARCengine motherboards, but not
> any
> SPARC workstation or server Sun has ever sold that I know of), so is
> installed only on those machines by a dynamic cluster test or as part
> of the
> All+OEM metacluster.
>
That's useful to know. So many of the Pkg's have useless Description
fields.
(They copy the Name field usually.) Another one:
Which 'older graphics environments' need SUNWCxsunserver?
>> Can you explain this:
>>
>> Why do packages in SUNWCxwrte require many but not all the libs from
>> SUNWCfontlibs, and SUNWxwrte doesn't include them?
>
> SUNWCfontlibs was made separate because the libraries are useful in some
> environments without X. (Okay, SUNWxwxft isn't useful without X, but the
> rest are - I don't remember why Xft got bundled in there instead of
> SUNWCxwrte.) There's not much in SUNWCxwrte yet that actually requires
> those, but the dependencies are expected to increase over time.
>
I can understand spliting it out.
Is there something that stops a package from being in two clusters at once?
I mean can't picking SUNWCfontlibs get you all the font libs, and
Picking SUNWxwrte some other time get you all the X11 run-time including
the required font libs?
I think SUNWCxwrte needed more than just SUNWxwxft though.
>> Shouldn't requesting an Xwindows Run-time environment actually
>> install a working runtime environment?
>
> Yes, but that's what package dependencies are for. I don't believe
> clusters
> are supposed to be all-inclusive, and I thought were mainly a way to
> easily
Maybe a jumpstart option to automatically resolve dependencies is in
order then.
> group packages in the install GUI package list and jumpstart
> configurations,
> not in any way a reflection of dependencies. There's a lot of things you
> need for a working X runtime that aren't in SUNWCxwrte - such as the
> kernel,
> libc, various kernel drivers, etc.
>
I aggree to a point. Most of what you describe is in SUNWCmreq.
Let's say I have a config that installs a working command line Solaris.
I want to add the ability to run X11 clients. As a user I'd expect
SUNWCxwrte to do this for me. If I want and Xserver too, then I'd expect
to need another cluster which I'd expect to include fonts.
If I install the Font server cluster without X11 on a machine I expect
to be a FontServer, I'd also expect to see all the fonts.
[Which brings me to another question... why are some fonts with the font
server, and others with in their own clusters? shouldn't they all be in
the fontserver cluster, or all be seperate?]
>>>
>> I agree that splitting the package would allow the dependency to be
>> specified at the a finer grain.
>> But I suspect that the java binaries dlopen the X libraries, instead
>> of being linked to them. right?
>
> Not as far as I'm aware - I don't know the Java internals, but I know ldd
> shows libX11 is linked into Java binaries like
> /usr/java/jre/lib/sparc/xawt/libmawt.so.
>
Yes, But I'd bet that libmawt is only dlopen'd if the java program uses
AWT classes.
I could be wrong though.
>> Is there any concept of an 'optional dependency' where it could be
>> noted that the base functionality of the package will work with out
>> the other package, but that functionality would be enahanced if it
>> was added?
>
> It would be nice to have a more sophisticated dependency system, perhaps
> like the one used for SMF services?
>
I only have a basic understanding of that, but anything would be better
I think. :)
-Kyle
