|
|
| Line 1: |
Line 1: |
| 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.
| | #REDIRECT [[RPM vs XO FUDConF11 BarCamp session 20090110]] |
| | |
| <pre>
| |
| <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*
| |
| </pre>
| |
