-----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/
/\\