Core-Dev application for Mario Limonciello (superm1)

[Stefan Potyra]

Hi,

On Tuesday 02 September 2008 20:54:37 Mario Limonciello wrote:
> On Sat, Aug 30, 2008 at 19:57, Stefan Potyra <sistpoty at ubuntu.com> wrote:
> > ok, however in this regard, I've got quite a heretical question to you:
> > As far as I understand it, DKMS builds modules on the users system.
> > Following
> > that practice, I have a dream to get rid of libraries changing SONAMEs.
> > Hence
> > I propose an application, which also rebuilds applications on the user
> > systems, and does so once a new library was found. What do you think of
> > this
> > approach?
>
> I've been thinking about this a bit since you wrote this idea.  At a glance
> it sounds like a great idea that would reduce overhead and maintenance of
> packages, but now I think unfortunately this will have to remain a dream
> for the forseeable future.  The thing is that the SONAMEs typically get
> bumped for a reason, eg ABI changes. 

Good catch :)!

> Sure, a lot of cases the ABI bump
> isn't relevant to the binaries that link to these libraries, but therre is
> no way to cover all of the cases.  

Yes, that's correct, esp. if you refer to binaries present (only) on a user's 
system.
Tough technical question: Nonetheless, it can be (and is in fact!) done the 
other way round, to determine which library version a binary package really 
needs. How would you do that? (or do you have any references in regards to 
this?)

[..]
>
> Could you imagine how much more CPU would be wasted if you had to pull in
> the entire OOo build system because the freetype library had an SONAME
> bump?  Maybe that example is a bit of an exageration, but I do think this
> would cause a lot more cruft on user's systems than would be desirable.

Good spot with the cruft. Actually it also is done (-> gentoo). With hard disk 
space being cheap nowadays, for the average user such a cruft is not too much 
of a problem though. Can you think of use-cases, where not having such a cruft 
(in regards to space) would be critical?

Finally, since you mentioned OOo, the main benefit actually (at least for 
myself) is -- as you correctly stated -- the CPU overhead. (and being a KDE 
user, who happened to rebuild kdelibs in the hope to fix a bug (without luck 
though) a few times, it is *no* exageration! ;).

>
> There is an argument from server teams that are against DKMS because of
> having to include a compiler on their servers.  Luckily, DKMS doesn't pull
> in more than just kernel headers in most cases which is much more
> acceptable for desktop systems.


Ok. In this regard, I'd like to ask you the following question:

If it has been not clear, I do believe that it's the task of a binary 
distribution to actually ship binary packages, which means that these don't 
get compiled on the users system. In contrast, DKMS does compile kernel 
modules on users system, which however could also be done on the buildds. 

Now I'm curious: You already mentioned that the small set of dependencies 
(kernel-headers and compiler) is s.th. that could mark a possible border line 
between "must get compiled on buildd" and "may get compiled on a users 
system". Can you give more arguments, why DKMS is a good citizen, compiling 
s.th. on the users system? Is there anything that can be achieved in this way, 
that cannot when compiling kernel modules on the buildds?

Finally, there are *other* cases, where s.th. gets compiled on the users 
system. Can you think of one case, and state why you think it's good that way 
(i.e. what shortcoming does it solve)?

Cheers,
    Stefan.