I think the .xo activities must be noarch only. These can be modified by teachers and kids, shared, you can "view-source" etc. The .xo can require the binary dependencies using PackageKit. Now we have one hundred activities based in GCompris and avery one must add the binaries and the activities like Phisics include the binaries for every plataform. Please don't reinvent the wheel. Gonzalo <div class="gmail_quote">On Tue, Sep 22, 2009 at 3:14 AM, Bernie Innocenti <<a href="mailto:bernie@codewiz.org">bernie@codewiz.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">El Mon, 21-09-2009 a las 23:50 -0400, Benjamin M. Schwartz escribió: <div class="im">> By having distinct packages built separately for each distribution by > experts. This is incompatible with our (or at least my) goal of allowing > users to throw packages around as atomic objects, without internet access > and without having to understand anything beyond "my friend has Sugar, so > it will work". It is also incompatible with allowing novices to generate > first-class Activities. </div>I withdraw my previous example. Admittedly, we couldn't rely on upstream for packaging up things even if we're using native packaging tools. <div class="im"> > This is also incompatible with your proposal to "choose RPM". The > equivalent here would be to choose RPM on Fedora, DEB on Ubuntu, ebuild on > Gentoo, tarball on Slackware, etc. </div>Yes, this is what I said initially: use native packages. RPM was just an example. Anyway, we'd have to provide different binaries for different architectures, distros, and even different distro versions. The temptation to simplify the universe and declare that there's just one CPU and just one OS is very strong. OLPC tried to take exactly this shortcut, but even in this idealized scenario it will break in many ways, given enough time: switching to ARM, upgrading to Fedora 42 defaulting to Python 3.0... <div class="im"> > >> I agree, switching bundle formats would gain us a lot of these features. > >> However, I don't think features such as dependency tracking are of much > >> use to us, because we can't trust system package managers, > > > > Why not? > > Because there is no way to build a single binary that will safely link > with all the different distros' libraries </div>Yes, we obviously need a multitude of binaries built for several distros and architectures. I thought this was implicit. Either this, or we decide that the XO-1 with Fedora 11 is the only platform that will ever be fully supported by Sugar. Can we afford to do that? Not really... <div class="im"> > > Why would we have to? Several good distros already exist... just pick > > one. No, actually, let's pick many! > > We can't pick one, because we wish to run on them all. We can't pick > many, because then users cannot share Activity bundles. </div>Hmmm, quite an unsolvable dilemma. Well, maybe not. We could make a few compromises that are actually quite acceptable in practice: * all "noarch" packages would be interchangeable between different CPUs * if two laptops happen to have the same architecture (highly likely within one school), they could exchange also the arch dependent packages * Even rpm could be made to work on non-rpm distributions, too. See <a href="http://kitenet.net/%7Ejoey/code/alien/" target="_blank">http://kitenet.net/~joey/code/alien/</a> . This is a bit of a hack, but still more robust than the XO bundles. * Direct exchange of bundles between nearby laptops could be seen as an optimization. If the package is not of the right kind, the other laptop would fall back to the online repositories Last, but certainly not least, * Activity sharing is not even implemented, yet! We'll think about these esoteric scenarios when they come... if at all. The "what if" engineering often results in really bad engineering. <div><div></div><div class="h5"> -- // Bernie Innocenti - <a href="http://codewiz.org/" target="_blank">http://codewiz.org/</a> \X/ Sugar Labs - <a href="http://sugarlabs.org/" target="_blank">http://sugarlabs.org/</a> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div> -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes