Hi Daniel,

I knew you would enthusiastically disagree with 'murmuring of 
loadscripts' :) 

> A. Writing a load script is trivial.

The script itself is trivial, but as I said you need to test it, 
meaning you have to run it AND test the resulting image. This is 
testing a release! If you have more than one loadscript it is 
something which is MORE work than testing a monolithic image release 
today. Have in mind here how many bugs, problems or not quite 
beautiful things are in the single image of today. 

There are not only packages depending on other packages, there are 
packages excluding each other, and this not only in a syntactically 
detectable way ( name clashes, class and method redefinitions ) but as 
I fear in many more subtle ways. E.g. programs produce data with 
data structures on disk, communicate with protocols, have semantics of 
their inst and class vars or have implications regarding the UI. You 
will not find such incompatibilities in an automated way. Something on 
top of assembled image A may not work on top of assembled image B or 
may hamper something in B, even if the dependency system gives green 
lights. 

These two points led me to the conclusion that it is best to keep the 
number of packages for the official releases as small as possible and 
the packages as big as possible. Of course it is a question of 
sensitiveness to find the optimal balance, but I really think that 
something like Diego's font-enhancement for the pref-panel is more a 
fix of something ugly - it should not be a package for loadscripts. 
This leads to Debian: Most modules of Debian are full blown 
applications or at least tools or libraries, they don't have minor 
tweaks and fixes which you can combine together to your personal 
system. 

The finer the granulation of modules, the more interface vs function 
there is, the bigger is the chance of problems. Debians module 
granulation is huge compared to the small SM-packages which I think 
about. 

> Just to make this factually crystal clear - the harvesters don't 
> harvest from SM.

Exactly because not everyone puts his code on the right avenue this is 
a problem. 

regards
Martin