Core-Dev application for Mario Limonciello (superm1)

[Mario Limonciello]

Hi Stefan:

Stefan Potyra wrote:
> 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?)
>   
Well ldd would show you which version you are particularly linked for,
but you are referring to symbol versioning.  I believe at least larger
libraries (such as glibc) provide this interface.  The application can
then check at runtime for the version of the symbol that is contained in
the library to determine if it's compatible.  I can't say I've
personally used this functionality in the past.
> 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?
>   
Diskless environments would be the first troublesome area that comes to
mind.  Diskless systems are generally administered directly on a server,
and depending on the scale of the diskless environment, this can be a
very largely duplicated effort for space.  If the diskless
implementation is using aufs or unionfs for an overlay filesystem,
performance will begin to suffer too.

>
> 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?
>   
By doing it this way, you can account for cases that were not
anticipated when the modules were first built on the buildds.  I'll try
to produce a theoretical example based upon a problem that may be coming
up soon.  Ubuntu Studio uses the -rt kernel, which starting with
Intrepid is no longer formally supported by the kernel team.   This
means that if the kernel team was to produce modules for the different
possible supported kernels, -rt wouldn't be included.  Either the
maintainers of the -rt kernel would need to go through and produce these
modules themselves, or ask the maintainers of this package to go and
build against an additional package.  Both situations require that
additional work be performed because of an unanticipated scenario.  With
DKMS, as the -rt kernel gets installed or booted on the system, the
modules are built for it without needing to get any of the developers
involved.

Another thing achieved here is to fully compile modules with
questionable licensing.  A volatile system is included for all modules
that are part of Linux-restricted-modules that will link the modules
upon boot.  As I understand, this volatile system is put in place
because fully binary modules can't be shipped on the CDs or hosted. 
Moving the entire compilation process to the end user's system absolves
any further risk of compiling or shipping any variant of the module on
the buildds.

As for DKMS being a good citizen, remember it's a framework.  It's up to
the maintainer of the DKMSified package to be the good citizen.  If a
destructive developer wanted to create a virulent kernel module, ship
all of it's source, and then compile it on the end user's system, this
is entirely feasible.  In some ways, DKMS actually makes such a task
easier for the destructive developer. 
> 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)?
>   
I'm not sure this is the example you are looking for.  When ldconfig is
ran, it builds a list of candidate libraries for applications that use
dynamic libraries to search through.  Without this type of
functionality, all binaries would be static and require a significantly
larger footprint both in hard drive space and memory.

Regards

-- 
Mario Limonciello
superm1 at ubuntu.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/motu-council/attachments/20080909/cf573ce7/attachment.pgp