From Fedora Project Wiki
Video of the session
http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF11/XO-vs-RPM.ogg
XO design goals not currently satisfied by RPM
- Installing by "getting from a friend"
- Kids can change and redistribute bundles.
- Kid bundles are "first class" (distributed versioning implies distributed dependencies)
- Don't break the world at install time
- Localizability in the absence of a cantralized repo
- Novice programmers using [Pippy]
Questions
- Should activities be noarch?
Wrap-up
- Short-term -- XO format not going away because of requirements not in RPM or any other package format.
- Other problems underneath -- development standards for activity developers. (What is testing, what is release.)
- This is the release, pull it from git, and build an installable package == something that helps XO and RPM potentially.
Short Term outcome
- keep the xo format and push on the activities addons infrastructure
- fructose (a basic set of activities) will keep on being packaged for the distros (debain, fedora, ubuntu...) offers a basic system to start from
- as fructose activities are installed by root every user on a multi-user system (school lab) have a basic system where he can not delete the core activities
- the core system follows a release cycle and quality standard
- show information in the UI when an activity can not be removed
Notes - other, raw
- Giving people freedoms and guidelines are not exclusive goals
- Reference point -- Firefox add-ons. Single platform question, then it installs; highly enables community of add-on (activity) creators.
- XO bundles are more like Java Applets than not -- from security framework, to the idea that you are grabbing and caching a webpage for playing with later.
Transcript
Transcript of Greg DeKoenigsberg's FUDCON11 session on .xo vs .rpm packaging for Sugar Activities, 2009 Jan 10 at 13:30-14:30 in Cambridge, MA, USA. Notes (including all errors) taken by Mel Chua, edits and revisions welcomed.
| mchua | (Mel: Everything here is paraphrased.) | |
| mchua | gdk: There's a whole bunch of questions tied up in writing Sugar Activities. Some of the questions pertain to some software development practices, and what practices Activity developers follow, like releases (what are they, should we have them, etc). | |
| mchua | We've done some strange things in this regard. A lot of the open questions are about packaging. | |
| * spevack (n=spevack@fedora/mspevack) has joined #fudcon-xorpm | ||
| mchua | Question: Are we going to reinvent an already existing package system, does it make sense? | |
| mchua | One of the main things to consider is user-installability. | |
| mchua | mstone: <something about how uruguay uses stuff> | |
| mchua | gdk: an .xo is basically a renamed .zip | |
| mchua | that's it | |
| mchua | We should enable people without XO hardware to be able to use this software. | |
| mchua | This is a common goal, to be able to use things across distros etc. | |
| mchua | (distros and other platforms) | |
| mchua | one of the open questions is that we have this list of Activities of varying maturity | |
| mchua | The .rpm way is to make them into .rpms | |
| mchua | so we could make them all .rpms | |
| mchua | Or we could just leave them as .xo files | |
| mchua | What are the strengths and weaknesses of this? | |
| mchua | cscott: could have them be installed via firefox extensions too. | |
| mchua | <discussion on firefox as an exception re: installing package-like things> | |
| mchua | jkatz: <discussion on firefox's versioning practices> | |
| mchua | gdk: the reason this works is that they can treat firefox as a complete platform, and don't need to know about dependencies outside it. | |
| * cjl (i=chatzill@ool-45735eb0.dyn.optonline.net) has joined #fudcon-xorpm | ||
| mchua | jkatz: When you make stuff for a project, you need to package according to that project's conventions. | |
| mchua | gdk: yes, but what do you package? You could imagine one .rpm with all of Sugar and another with all of the Activities. (Instead of individual ones for each Activity.) | |
| mchua | bschwartz: Activities are independent of one another. One way of thinking about it is Activities are things you run through Sugar, like running scripts in a scripting environment. (Mel: This may be misphrased.) | |
| spevack | much like you have a gnome-games packages that represents a bunch of the best/most stable games available for gnome in a given release (i'm sure someone will make this point) | |
| spevack | you could a single rpm that provides a whole bunch of activities. | |
| * spevack doesn't know what he's talking about :) | ||
| mchua | cscott: As an example, think of Java games, you can download games and run them in Java, but you don't re-download Java for each game. Unless you need 2 different versions of Java. | |
| mchua | spevack, is that something you want relayed to the room? (haven't looked around enough to see if you're here) | |
| mchua | bschwartz and cscott: <discussing the lack or presence of Activities as dependencies of each other> | |
| * tomeu1 (n=tomeu@r9ci216.net.upc.cz) has joined #fudcon-xorpm | ||
| mchua | bernie: We can get new volunteers started dong simpler packaging work. | |
| mchua | cscott: why can't we package them both as an rpm and have a native package format? | |
| mchua | bschwartz: we are doing that. | |
| mchua | jkatz: <talking with bernie, I can't catch it> | |
| mchua | gdk: Let's talk about the design. | |
| spevack | mchua: nah, don't interrupt greg's flow | |
| * mchua nods to spevack | ||
| * spevack is not there, unfortunately -- just following along remotely via your transcription | ||
| mchua | gdk: one of the principles of sugar is collaboration - they can share easily with each other, they don't have to set up complicated things on their computer to do it. | |
| mchua | bschwartz: this is a design goal, regardless of implementation. | |
| mchua | bernie and jkatz: <questions about implementation> | |
| mchua | cscott: no no, it's a design goal. | |
| mchua | The second design goal is that the Activities would be user modifiable using tools that are on the laptop. | |
| mchua | gdk writes on board: 1. Installable by "getting from a friend." | |
| mchua | (Mel: This means not just collaboration, but if a friend has an Activity you don't, you can install it by just getting it from him or her, just as if you were collaborating on an Activity you already had.) | |
| mchua | gdk writes on board: Kids can change and redistribute bundles. Kid bundles are "first class." | |
| mchua | bschwartz: what this means is that if a kid has an Activity and they edit it and redistribute it, their new Activity isn't any "less a real Activity" than one that say the people in this room work. | |
| mchua | This also means that version numbers get a little weird when software is forking so often. | |
| mchua | In ways that are not necessarily centralized. | |
| mchua | gdk on board: Don't break the world at install time. | |
| mchua | gdk: some of these features are Sugar differentiators. A lot of the points we are making (Mel: and that I missed typing - details not as important) boil down to "collaboration." | |
| mchua | Collaboration, to me, is the whole thing that makes Sugar interesting. peer to peer collaboration. | |
| * |tanya| (n=tanya@dhcp-18-190-60-36.dyn.mit.edu) has joined #fudcon-xorpm | ||
| mchua | mstone: Don't forget about localization. | |
| mchua | gdk on board: Localizability | |
| mchua | jkatz: There are a couple of things to look at - is Sugar intended to go beyond kids? This has a lot of implications. | |
| * mchua is happy to relay questions from the channel, for the record - |tanya|, spevack, tomeu1, cjl. | ||
| spevack | thanks | |
| mchua | jkatz: The second thing is... well, we saw this problem, we didn't like how it was done, so we made our own system instead of trying to work with the systems that exist. | |
| mchua | Maybe it's the right answer, but there is a larger context of software that this fits into. | |
| mchua | gdk: That begs the question - is there enough of a commitment here to solve the problems that you're talking about? Maybe one of the problems, for example, is user infallibility. | |
| cjl | Thank m_stonefor raising localization, to many Activitiesdon't have POT in Honey. | |
| mchua | marcopg: <complaints about .rpm shortcomings> | |
| mchua | gdk to marcopg: Are those really? | |
| mchua | (Mel: Overall notes - jkatz is providing a lot of excellent constructive skeptical criticism - cscott and bmschwartz are teamed up countering them, and gdk is summarizing and refocusing every so often.) | |
| mchua | gdk: Giving people guidelines != not giving them freedom. If we want to make an ecosystem, there are some assumptions we are going to have to tell people they might want to opt-in on. | |
| * |tanya| has quit () | ||
| mchua | mstone: <discusses shortcomings of the .xo system in reaching the goals gdk wrote on the board> | |
| mchua | bmschwartz: Yes, we're far from them, I'd like to talk about how we can get there. | |
| mchua | cscott: We're not that far in some respects. | |
| mchua | <discussion on how far or near we are from some of these goals> | |
| mchua | gdk: Let me ask this: is dependencies something .xos should care about? | |
| mchua | If so, we're going into the packaging world, because that's the problem packages were supposed to solve. | |
| mchua | jkatz: At the very least, you need to have the "you need this version of Sugar to run this." | |
| mchua | bmschwartz: We have that. | |
| * |tanya| (n=tanya@dhcp-18-190-60-36.dyn.mit.edu) has joined #fudcon-xorpm | ||
| mchua | gdk: having a piece of software be a platform != having a piece of software worry about dependencies - look at firefox! | |
| mchua | It's cross-platform and essentially a platform of its own. | |
| mchua | There are things it doesn't do that people in the "enterprise system" care about, like the ability to see what software is on the system at any given time. | |
| mchua | The question is what the tradeoff is. | |
| mchua | bmschwartz: maybe we need a way for these things to be created by novices. | |
| mchua | gdk writes on board: novice programmers using pippy. | |
| mchua | (Mel: for context, see http://wiki.laptop.org/go/Pippy) | |
| mchua | cscott: All linux distros I know of have a canonical source of packages - centralized. If we really believe kids are modifying packages, that centralization goes *poof* | |
| mchua | You get all sorts of microversions. | |
| mchua | gdk: Distributed versioning with dependencies? *screams* | |
| mchua | bmschwartz: Is one design assumption we are making that these kids might not have internet connectivity - only mesh networking with other local kids? | |
| mchua | cscott: A lot new version control systems were made because of this need to be distributed. | |
| mchua | bmschwartz: and maybe one of the things .rpms *can't* be made into is a distributed versioning system. | |
| mchua | cscott: maybe version numbers fundamentally don't work in this case. | |
| mchua | jkatz: Is this something the Sugar community feels strongly enough is vital to Sugar's success that you're willing to make those tradeoffs? | |
| mchua | cscott: I don't see these options as an either/or. | |
| mchua | You can package things whatever way you want. | |
| mchua | gdk: Right now, we have a handful of .rpms, and all the Activities are .xos. You install them as .xos. | |
| mchua | when I have to figure out whether I should go to the work of bundling up XOirc, or if I should just get the .xos, there's no incentive for me to do the former. | |
| mchua | It's just so easy to do the former - trivially easy to download it from the website and it Just Works. | |
| mchua | jkatz: But if I have a lab of many machines, does that "trivially easy" change? | |
| mchua | gdk: This is the enterprise systems question. | |
| mchua | cscott: It used to be you packaged because you had multiuser systems and you wanted everyone to have it. | |
| mchua | jkatz: this design makes life hard for sysadmins. | |
| mchua | bmschwartz: another design assumption is "we don't have sysadmins." | |
| mchua | gdk: From my practical experience, the reason I want to see packages for other kids of software is that other software is complicated in a way Activities are not. | |
| mchua | <protest from room> | |
| mchua | gdk: so hear me out! Having to do things with complex makefiles, etc- ok, yes, you need rpms! | |
| mchua | but the problem of installing a bunch of python files is totally not the same. | |
| mchua | if I'm doing something like "install paste," then zomg, I want an .rpm and if need be I'll be the one that does it. | |
| mchua | but for installing an Activity, then... | |
| mchua | bmschwartz: extension of this thinking - we don't need a package manager to install html webpages. we just http get them and view them. | |
| mchua | Activities are on that end of the spectrum. | |
| mchua | bernie: <story about his friend porting Mono activities to the XO - summary was "It took him a few days."> | |
| mchua | bmschwartz: I wrote an Activity, most of my work was writing shell scripts that unbundled .rpms. | |
| mchua | (Mel: referring to an Activity he ported over from rpms, I believe.) | |
| mchua | mstone: Fedora has, understandably, very strict guidelines about where things should go. | |
| mchua | jkatz: Getting people to follow those standards is hard - if you write a standard nobody follows, that's no good. | |
| mchua | jkatz: there are ruby gems, etc. | |
| mchua | .jars, etc. | |
| mchua | jkatz: <description of how one such standard within fedora became adopted> | |
| mchua | Maybe we're all sitting here worrying about this for naught, when the point is really what the community will end up using anyway. | |
| mchua | bernie: how much would it take to switch to packages? | |
| mchua | marco, michael: <side conversation about this that I can't quite catch> | |
| mchua | (the summary of what marco and michael are saying is mostly "not very hard") | |
| mchua | bmschwartz: the .xo isn't the only thing that has been recently designed to solve the problem of installing arbitrary apps with no root access. | |
| mchua | cscott: This is like a pendulum - when we had big multiuser systems and nobody had root, everything was local install. Then we had people with root on their own systems, and installing stuff as root became ok. | |
| mchua | then now we have this new idea of a multiuser system where the users aren't necessarily different people, but different aspects of you - and each program then has different permissions for things that you're giving it access to see. | |
| mchua | (Mel: see bitfrost and rainbow stuff on the OLPC wiki.) | |
| mchua | (for context.) | |
| mchua | jkatz: It's like xguest (Mel: did I get that right?) on the latest Fedora. | |
| mchua | bmschwartz: we need to generate a system that automatically applies security to .xos that get installed. Sugar hasn't been able to find an existing system that they can borrow for this yet, hence "make your own." | |
| mchua | The only thing we need different from .rpms is this non-root installation. all the other problems are same for .xos and .rpms. | |
| mchua | My question is "do you want rpm to become the new usermode packaging installation system?" | |
| mchua | jkatz: since new people have taken over rpm - we need to fix the problems that exist now before we build more things on top of it. | |
| mchua | user installation is a goal, but a long-term one not on an immediate time horizon. | |
| mchua | (user-level installation, in the sense of security - nonroot.) | |
| mchua | bmschwartz: what using .rpms would gain Sugar devs is that it would save us the trouble of maintaining .xo management tools - not so that we can install through yum or anything. | |
| mchua | gdk: nearly out of time. time to wrap up. | |
| mchua | short version is that .xo isn't going to go away because other solutions like .rpms aren't there yet. | |
| mchua | in the meantime, it seems that there are other problems underneath this level to be considered | |
| mchua | like development standards with Activities. | |
| mchua | for instance, there's no way of tagging a particular release as being released vs unstable, etc. | |
| mchua | jkatz: that's one thing that distributed version control makes harder - centralized vcs has releases as "release == this snapshot in time." | |
| mchua | gdk: we need the ability to tag something in git as "a release." | |
| mchua | bmschwartz: my hope is that there will be lots of awful software written for Sugar. | |
| mchua | that a lot of stuff for Sugar will be written by people that barely know how to program. That would be wonderful. | |
| mchua | gdk: the key is making that stuff nondestructive. | |
| mchua | <session wraps up> | |
| mchua | *applause* | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!