[lsb-discuss] [klik-devel] third party packaging

Leibowitz, Michael michael.leibowitz at intel.com
Sun Oct 22 17:19:26 PDT 2006


While I think that encapsulating applications into AppDirs is
interesting, I think that it alone is not a full solution.  Klik is does
what it does well, but there are a few areas that I find problematic.
The app-image approach only handles packages that are simple
applications.  What if I wanted to package a high-performance math
library or something like VMware?  What if I wanted to package a suite
of software that inter-depended on each other (such as a high-end CAD
suite)?  Also, the limitations of FUSE or loopback mounted images starts
to come into play for large applications or for shared systems.  The
lack of any sort of manager leaves a system administrator completely in
the dark as to what software users have installed on their systems.
Could an administrator quickly and easily find out how many copies of a
vulnerable application where on their network?  I fell that a solution
for third-party packaging should work for nearly all third-party
packages for almost everyone.


--
Michael Leibowitz
Software Engineer, Channel Platform Solutions Group
Intel Corporation
michael.leibowitz at intel.com
+1 503 264 7621


>-----Original Message-----
>From: klik.atekon.de at googlemail.com
[mailto:klik.atekon.de at googlemail.com]
>On Behalf Of probono
>Sent: Saturday, October 21, 2006 6:42 AM
>To: Leibowitz, Michael
>Subject: Re: [klik-devel] third party packaging
>
>Hi Michael,
>
>I'd like to suggest for consideration that a package manager is not
>necessarily the best way to manage _all_ types of software. klik
>(http://klik.atekon.de), for example, it is intentionally built not to
>interfere with the operating system's package manager.
>
>The base system is provided by one vendor (e.g., Ubuntu, Suse, Red
>Hat,...). In my  opinion, the base system should provide a
>LSB-compliant platform, including one of the two commonly used
>desktops, and little else. This base system  should be managed by the
>native package manager, and no "external repositories" should be
>allowed to interfere with it.
>
>High-level end-user applications, such as Firefox, OpenOffice, SAP,...
>you name it should best be kept as "encapsulated" as possible (i.e.,
>they should not be intermingled with the base system), and should not
>interfere with the base system at all - Apple does this with
>application "bundles", directories that contain everything the
>application needs to run on the given base system. (At least in theory
>- but the implementation is not rigorous.)
>
>By having a strict separation between the base system (which is
>managed by the distro provider) and end-user application software,
>system integrity can be ensured even if one uses a lot of additional
>third-party software, since the state of the base system is never
>changed.
>
>Even Mircrosoft starting to "get it":
>http://www.softricity.com/products/virtualization.asp
>
>klik will go this direction.
>http://img61.imageshack.us/img61/458/plashso8.jpg
>
>Of course, writing a little app that checks for version numbers and
>automatically updates would be easy, if not trivial, to add to klik.
>
>Happy to hear your thoughts on this.
>
>Best regards,
>Simon




More information about the lsb-discuss mailing list