[Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work

[Sascha Silbe]

On Wed, Feb 18, 2009 at 07:36:18PM -0500, Luke Faraone wrote:

> The *ideal* method would be to use a standard packaging method long 
> term, ie
> .deb (which I'm partial to) or RPM. (both of these can be converted 
> from and
> to each other with alien)
What exactly are you refering to when you say .deb / .rpm? File format, 
method of access or conventional means of operation?

As for the file format, I think most file formats can be suited to our 
needs - some may need more tweaking, some less. How much exactly will 
depend on how we expect the final solution to work.

For access methods, the situation similar, though potentially a bit more 
complex: while having apt archives for "common" packages would be great 
(and could be set up at each school), we still need to cater for the 
"meeting in the middle of the jungle" use case (*).
XO-local apt/http repositories might be useful - worst case would be 
trading individual .deb files and having an installer refusing the 
install them (with a kid-friendly error message ;) ) unless all of its 
requisites have already been installed.

The most interesting part is architecture dependency: we shouldn't (and 
in general simply cannot) assume that the activity author is able to 
provide binaries for all architectures that anyone interested in running 
the activity might use.
This means we need to be able to get the source, either bundled directly 
with the binaries like in my proposal [1] or as a separate source 
package from the same repository (deb-src lines in sources.list).
Personally, I prefer always having the source (even more so since Sugar 
now has first-class "View Source" functionality), but there's nothing 
about .deb's preventing this: just think of the source package as "the 
activity" (library/whatever) and the binary package as "precompiled 
architecture-dependent bits for the activity".

Strangely, the more I try to take your answer apart, the more I find it 
could actually be made to work. :-P

> Currently the main objection to using "system packaging" is that they
> require administrative privlages to install; unfortunately, so would 
> any
> other solution other than requiring that *all* sugar installs had 
> *all* the
> packages in the "sugar system" (like we were able to do with the XO).
It isn't all black and white. As you mention yourself, you don't need 
any administrative privileges to use apt ("prefix mode"). Actually on my 
regular system I install most software (that's not available in Debian) 
as a regular user (though using GNU stow instead of apt).
There are some interesting problems to solve for the gray area, though:

1. Ensuring integrity: a malicious dependency might subvert a lot of 
activities. For activities with enhanced rights we could require 
all-inclusive packaging, but that won't help in general (activities 
would get too big) and increases the next problem:
2. Ensuring currency: a dependency with known vulnerabilities might 
impact a lot of activities.

While Bitfrost is supposed to reduce the impact of a subverted activity 
(**), there's a difference between a single activity (that could 
possibly be replaced with a known-good copy) and half of the system not 
working properly.


(*)  Don't let that exaggeration fool you: Even in the "developed 
countries" ubiquitous internet access isn't a reality for most people. 
Requiring access to non-local repositories would severly impact the 
ability to trade activities.
(**) The fact that there currently is no implementation of it on non-XO 
systems should be fixed ASAP, not taken as an argument against at least 
partially relying on it. The Bitfrost specification was the main reason 
I took a closer look at Sugar in the first place.
[1] 
http://sugarlabs.org/go/ActivityTeam/PackagingIdeas#combined_Source.2BBinary_package

CU Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090219/b0c0f28c/attachment.pgp