Mailinglist Archive: opensuse (2831 mails)

< Previous Next >
Re: [opensuse] Re: MiniSUSE project page.
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Sun, 23 Jul 2006 10:21:29 +0200
  • Message-id: <44C33189.4000003@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rajko M wrote:
> Pascal Bleser wrote:
>> jdd wrote:
>>>> Pascal Bleser wrote:
>
> <snip>
>> Sounds to me like you should use Gentoo instead of SUSE Linux.
>> But Gentoo has other problems.
>
> The basic problem with Gentoo is that any major change locks computer
> for a long time until compilation is done. No one that uses Gentoo is
> rushing to get the newest KDE, just to try.

Right. And their dependency management doesn't work that well.

But on Gentoo, as you build (almost) everything from source yourself
anyway, you have a very fine grained (build/compilation) configuration
of what features you want and what features you don't want.
As an example, if you don't want Ogg/Vorbis anywhere, you can define
that more or less globally for your system.
But when you change such a "USE flag" (how they like to call it ;)), you
might have to rebuild almost all your distribution (that's not a cup of
coffee, that's usually 2 or 3 days without a working system).

So, yeah, fine-grained control over features you want to be compiled in
or not, but Gentoo has its own share of problems and most importantly,
it requires a *lot* of work to tweak and maintain your system.

(note, this is not a rant against Gentoo, they have a very healthy
community and for certain scenarios, it is a very good solution)

>>>> all this I _have_ encountered
>>>> Yast is not at present time sufficiently fine grained to cope with this.
>> YaST2 has absolutely nothing to do with that.
>
> I'm afraid that you are right. It has little to do with YaST. We can
> tweak selections and achieve some improvements, but to make SUSE linux
> really slick, we have to find the ways to overcome rpm packaging
> limitations.

I wouldn't say it's rpm packaging limitations.
It's how the .spec files are written for SUSE Linux (or miniSUSE).

Take an example: kdelibs3.
kdelibs3 contains all the basic KDE libraries and core services (note
that normally you need at least both kdelibs3 and kdebase3 to have a
working KDE desktop, as kdebase3 contains more stuff about konqueror,
etc...).
The package weights 120MB of disk space:
$ expr $(rpm -q --queryformat="%{SIZE}") / 1024 / 1024
119

If you look at all the files it contains (rpm -ql kdelibs3 | less), you
can see that there's a lot of stuff in there, and you most probably
don't need all that if you just install an application that requires KDE
shared libraries (to resolve its symbols through the dynamic loader, as
explained in my previous mail) and you use, say, a GNOME, XFCE, fluxbox
desktop.

Say you use fluxbox or XFCE as a window manager, but you want to use amarok.
amarok has been built against shared libraries that are contained in
kdelibs3 (amongst other things, such as xine, etc... - but let's just
consider the KDE dependency for the sake of simplicity).

Let's have a look at amarok's shared library dependencies (remember, I'm
only showing the QT/KDE dependencies here):
$ ldd /opt/kde3/bin/amarok | cut -f 1 -d " "
[...]
libkdecore.so.4 => /opt/kde3/lib64/libkdecore.so.4
libqt-mt.so.3 => /usr/lib/qt3/lib64/libqt-mt.so.3
libDCOP.so.4 => /opt/kde3/lib64/libDCOP.so.4
libkdefx.so.4 => /opt/kde3/lib64/libkdefx.so.4

For RPM (and YaST2, rug, smart, apt, ...), that means you also have to
install the following packages:
$ rpm -qf /opt/kde3/lib64/libkdecore.so.4
kdelibs3-3.5.3-7.1
$ rpm -qf /usr/lib/qt3/lib64/libqt-mt.so.3
qt3-3.3.6-37.1
$ rpm -qf /opt/kde3/lib64/libDCOP.so.4
kdelibs3-3.5.3-7.1
$ rpm -qf /opt/kde3/lib64/libkdefx.so.4
kdelibs3-3.5.3-7.1

We can automate that somewhat ;)

$ ldd /opt/kde3/bin/amarok | cut -f 3 -d " " | while read lib; do \
[ -n "$lib" ] && rpm -qf "$lib"; done \
| sort |uniq

Here's the output, again, only considering QT and KDE:
kdelibs3-3.5.3-7.1
qt3-3.3.6-37.1

So when you install amarok, you'll get the full kdelibs3 (120MB) and qt3
(56MB) packages onto your system, although not everything inside those
packages is needed just to run amarok (on a non-KDE desktop).

The "solution" to solve that "problem" is to split the kdelibs3 RPM
package into several smaller bits, e.g. one package that really only
contains libkdecore.so.4 + libDCOP.so.4 and another one that only
contains libkdefx.so.4, as those are most often required by KDE
applications.
Same for qt3: have a package that only contains the core library
(libqt-mt.so.3)

That way you would only install 58 MB for the KDE/QT dependencies:
- - libkdecore.so.*: 9MB
- - libkdefx.so.*: 692K
- - libqt-mt.so.*: 49MB

So much for the technical background.
Note that I'm really, really oversimplifying here, and in practice it is
much more complex to find a solution to that "problem".

The more packages, the more complex the build and package management
becomes. Ultimately, you'd end up with one or two files per subpackage,
and I guess the system could become really hard to manage.

Also, there are a lot more dependencies to consider, I really only kept
the KDE and QT ones here, but you also have Xorg, libpng, zlib, GCC C++
runtime libs, and much more stuff that amarok loads through plugins
(MySQL client libs, PostgreSQL client libs, sqlite3, ...).

Keep in mind that this is also pretty much a case by case analysis, and
that a lot of time and effort must be spent into looking at such
packages, which files are usually required by most other packages, which
files are necessary to make a KDE application work (e.g. you might also
need a few .desktop files, a few binaries like knotify, etc... to
actually make amarok work properly).

> The miniSUSE is a project that needs a lot of data, before it can
> produce real improvements, it can influence application writing and
> packaging philosophy as we know it today. What we need is more heavy
> weights like you that have deep understanding of present status and
> possible ways to go around.

Well, yes, in theory.
You can effectively improve the situation through RPM packaging, but
that doesn't solve the other issue I explained in my previous mail (see
below).

> <snip>
>
>> For some applications, it's possible to do that though, because they
>> externalize their features/capabilities as plugins (usually shared
>> libraries loaded with dlopen() or libtool/libltdl) and are smart enough
>> to disable features if the corresponding plugin could not be loaded.
>>
>> But that's really the exception, and not the rule.
>> 90-95% of applications don't work that way and burn dependencies into
>> their binaries at compile time (usually depending on what you pass to
>> the ./configure script), not at runtime.
>
> Nice point.

To "solve" that, you'd have to tell hundreds of software developers to
completely change their sources, to try to externalize dependencies
through plugins. Understand that it's often a lot more complex to
implement an application that way (and sometimes it's even not feasible
at all).
More complexity means more error-prone... which means more bugs and less
quality.

IMO that's just not possible.

> That points one of the ways to overcome present status, more smart
> applications, that adjust themselves to existing environment. To cut on
> load time, check has to be done only if system indicates new installed
> plugins.

Hm? "check" ? what check ?

Applications must be written to load features as plugins.
e.g. MySQL client support for amarok
amarok should try to load every .so file that's in /opt/kde3/lib64/amarok/

If you don't have the necessary MySQL client shared libraries installed,
the dlopen() call on e.g. /opt/kde3/lib64/amarok/mysql.so will fail
The application must be so smart to say "ok, could not load that plugin
for some reason, so just ignore it and don't have that feature".

That sounds really simple, but it isn't, it really isn't...

> To cut on multitude of ways that kind of checkup can be done and the
> number of ways that plugin communicate to main application, we need
> operating system to take over setup procedure and include some standard
> way for communication between processes.

Ewww... stop stop stop ;)
You are running into the wrong direction here ;)

The kernel has absolutely nothing to do with that.
The necessary stuff to work with plugins is already available: it's
dlopen() (or libltdl from libtool, does the same in a slightly simpler way).

There's no need for "communication" either.

> <snip>
>
>> I'm afraid you are dreaming of something that is not technically feasible :\
>
> Not in a short term, but set as a goal it will produce results.
> Linus dreaming is what brought Linux to us :-)
> All we have to do is to continue the dream.

Well, yeah, you could also dream of having a car that drives 800 km/h,
has room for 5000 liters of luggage, and all that for 100 EUR, but it's
still not feasible - at least it's not realistic ;)

cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEwzGJr3NMWliFcXcRAjTLAJ9l65r2cyfnAp30QF0pa5QsrshfrQCfXYZf
XL9rvVFZom89LUEQ46wp1cw=
=Tlcc
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-help@xxxxxxxxxxxx

< Previous Next >
Follow Ups