On 7/12/05, Glynn Foster <[EMAIL PROTECTED]> wrote:
> So the obvious questions that come to mind that we probably need to
> discuss are -
>
> o Why aren't these tools already available on Solaris?
> o Why can't we use the non-GNU equivalent? And if not,
> why can't we fix those tools?
> o What's the roadmap/development for this and how can
> we effectively coordinate when KDE/GNOME/Others require
> a different version set?
Hi.
Here it is. i'm trying to keep it as short as possible.
i was not referring to the GNU auto* tools, or GCC. the auto* tools
are mostly scripts (with the exception of libltdl), and they aren't
that hard to upgrade or back out. as far as GCC goes, that's a little
above my pay grade. it would be very arrogant of me to tell Sun what
compiler to include in their distro. so i never dreamt of going there.
:-)
i was referring to all the libraries on which both GNOME and KDE have
dependencies. for example: libxml2, libxslt, libpng, libz, libjpeg,
etc, etc.
currently, the situation seems to me a little out of control. there
are so many independent distros, each and every one of them with their
own versions of these lib dependencies. which makes for a not so nice
experience for someone installing independent distros of KDE or GNOME,
or something even worse: they end up with 3 or 4 different version of
libxml2 for example, in different places! now, realistically speaking,
how many versions of libxml2 does one really need on a box ? :-) same
goes for most of the other dependency libs.
so my idea was: would it be possible to work together and create a
common and consistent foundation for OpenSolaris, for these dependency
libraries, for GNOME/JDS and KDE and anything else ? i fully realize
this is no easy task, and it probably will be very time consuming to
sift through every single one of them, and find a common version which
works with both. but i am thinking that the alternative -- which is
continuing this inconsistent setup for these dependency libraries --
is worse. the idea being that: we would find the common version for
these libraries which works on both JDS/GNOME and KDE, and that
version would become the "official" version. and consequently, any
upgrades to these libraries would have to maintain the same
compatibility rules.
the way i understand it, these dependencies fall in three categories:
1. common to JDS/GNOME and KDE (just for demo purposes let's call it
"osde-core")
2. specific to JDS/GNOME ("osde-jds")
3. specific to KDE ("osde-kde")
and then a fourth one which is really a subset of (3): KDE has
dependencies on gstreamer,
scrollkeeper and glib/gtk, which are part of JDS/GNOME. as a side
note, my packages are linked against the Sun JDS/GNOME gstreamer, and
the Gimp screenshots are with the Sun JDS Gimp.
the benefits of this would be:
- a common, consistent core foundation
- more appeal to the "outside contributor" -- meaning, if OpenSolaris
comes out of the box with these dependencies in a familiar place, it
is much easier for someone coming from the GNU/Linux world to get
accustomed to this new environment: pretty much the familiar things
are there.
- make our lives easier down the road, given the fact that both GNOME
and KDE release quite often
as to where exactly these things should go: i don't know if it is my
place to say things like "this should go here and that should go
there". i think this should be part of our conversation, and be a
consensus decision.
for the business reason behind this:
the young generation. the 16 or 17 year old with a knack for
programming: their choices up until this year were: Win32 (most
likely), or Linux (less likely but possible). as of this year, Solaris
is also a choice: it can be downloaded free and installed on a home
PC. we all know here that Solaris is the powerhouse enterprise server.
but, the 16/17 year old in question will probably not experience
Solaris, for the first time, as an Enterprise-class server. it will be
on their home PC.
and now finally (and briefly i promise) what's in /opt/fsw4sun and why
it is there:
what's in it: everything + the kitchen sink (from libpng to openldap
to libdvdread to xine to samba3 to glut 3.7 to icecast 2.2 which can
stream video to my build of libGLU/libGLw and libOsMesa to PostgreSQL
to GNU su/ls/cp, and so on). all of them built with SunStudio10 (on
IA32) or SunStudio9/SunStudio10 (on SPARC).
why it is there: i started working on KDE back in the Fall of 2002.
that was on Solaris 8 SPARC. at that time, a lot of KDE's dependencies
were not available on the Companion CD, and those which were
available, were built with GCC. in C++, GCC and Forte 7 are ABI
incompatible. so, i had to rebuild with Forte. why it is called
fsw4sun: my target audience at the time, were the members of the
kde-solaris community/mailing list. their main requirement was not to
overwrite any potential install of these libraries somewhere else on
their system, and keep the KDE packaging self-contained to a maximum.
this pretty much excluded /usr/local (which is where Sun Freeware
lives). so i had to come up with a directory name which would not
conflict with anything, and i came up with this very lame name and i
take full responsibility for it. the only advantage to this lameness
being that i was almost certain noone else could come up with
something so ugly. then what started as an experiment became
established practice for my builds, so that's the reason it is there.
why kde installs in /opt/kde-<version>.<major>.<minor>: i wanted to
make it as easy as possible for anyone to install a new version
without overwriting an existing one, which they may currently use, and
like. the other reason, because /opt is traditionally the place where
SVR4 external software goes. these are the only reasons.
sorry if this was too long. i really tried to make it as concise as i could.
--Stefan
--
Stefan Teleman
[EMAIL PROTECTED]
_______________________________________________
opensolaris-discuss mailing list
[email protected]
