[lsb-discuss] [Desktop_architects] Third party packaging

Leibowitz, Michael michael.leibowitz at intel.com
Wed Oct 25 15:10:02 PDT 2006


Moving this to lsb-discuss to avoid a forked conversation.  

I do know of Autopackage, but I'm not sure I agree with you that it is a
complete solution.  I see that autopackage has done a really good job of
1).  I will also note that the ability to install as non-root is also
nice.  

However, it seems that Autopackage's approach to 3) is to overwrite
things in /usr.  I understand that this is largely because /usr/local is
broken on most distros out of the box.  Hoewver, I think that the
distros see Autopackage's approach to doing the RightThing as not the
RightThing.  

With regards to 4), it seems that the database is fairly rudimentary.
This isn't a flaw per say, but can it scale?  Are there tools to query
the database in the same way I can with dpkg or rpm (what is the state
of package xxyyzz?  What files did xxyyzz put on my system?  Where did
the file /xx/yy/zz come from?)?  Are there locking constructs and
recovery mechanisms to ensure that my database doesn't get corrupted?

Also, I'm wary of the whole idea of the executable package format.  With
non-executable packages that are manipulated with tools on my system, I
can check the package signature and examine the package to see what it
does before letting it loose on my system.  With an executable package,
I cannot trust it to provide me a signature and I may not have tools to
analyze it.  Furthermore, analyzing executable packages is a little
tricky.  

If I don't get 2), 3), and 4), then why is it appreciably better than
Klik?  Because of Klik's self contained nature, I know that it won't
interfere with any distro mechanisms and can be easily removed if the
package is broken/unusable/I don't want it anymore.

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


>-----Original Message-----
>From: mh.in.england at gmail.com [mailto:mh.in.england at gmail.com] On
Behalf Of
>Mike Hearn
>Sent: Tuesday, October 24, 2006 4:42 PM
>To: Bastian, Waldo
>Cc: desktop_architects at osdl.org; Leibowitz, Michael
>Subject: Re: [Desktop_architects] Third party packaging
>
>Michael Leibowitz described autopackage, but apparently isn't aware it
>exists. It meets his requirements except for 2:
>
>1) A unified and simple UI for installing/removing/updating packages
>that is the same regardless of distro or desktop environment
>
>2) Ability to detect, alert, and install updates when they are
available
>
>3) Proper interaction with the distro, including doing the RightThing
>when the distro and package have a mutual interest in a file or service
>
>4) A database of installed packages, files, and assorted
>meta-information that can be queried
>
>It does have the distinct advantage of actually existing :) Adding
>auto-update support to autopackage would be far easier than
>re-inventing all this from scratch  ....
>
>thanks -mike
>
>On 10/23/06, Bastian, Waldo <waldo.bastian at intel.com> wrote:
>>
>>
>>
>>
>> People interested in third party (non distro-specific) packaging may
find
>> the following discussion on lsb-discuss interesting:
>>
>> http://lists.freestandards.org/pipermail/lsb-discuss/2006-
>October/003085.html
>>
>>
>>
>> See
>> http://lists.freestandards.org/mailman/listinfo/lsb-discuss
>> for subscription info.
>>
>>
>>
>> Waldo Bastian
>>
>> Linux Client Architect - Client Linux Foundation Technology
>>
>> Channel Platform Solutions Group
>>
>> Intel Corporation - http://www.intel.com/opensource
>>
>> OSDL DTL Tech Board Chairman
>>
>>
>> _______________________________________________
>> Desktop_architects mailing list
>> Desktop_architects at lists.osdl.org
>> https://lists.osdl.org/mailman/listinfo/desktop_architects
>>
>>
>>




More information about the lsb-discuss mailing list