RPM vs XO FUDConF11 BarCamp session 20090110

XO design goals not currently satisfied by RPM

1. Installing by "getting from a friend"
2. Kids can change and redistribute bundles.
   1. Kid bundles are "first class" (distributed versioning implies distributed dependencies)
3. Don't break the world at install time
4. Localizability in the absence of a cantralized repo
5. Novice programmers using [Pippy]

Questions

1. 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*