[Sugar-devel] Bundling libraries, RPMs? (was Re: WatchMe-1, a VNC activity)

[Peter Robinson]

On Mon, Aug 17, 2009 at 10:34 PM, Gary C Martin<gary at garycmartin.com> wrote:
> Hi Peter,
>
> On 17 Aug 2009, at 21:20, Peter Robinson wrote:
>
>>> In an LTSP environment, no sysadmin is going to choose a policy that
>>> allows users to install packages, even trusted packages, to the root
>>> system, or otherwise make any sort of modification that cannot be
>>> trivially and reliably wiped clean.  PolicyKit will work fine, in that it
>>> will happily enforce the policy, which is "no installation allowed".
>>
>> In an LTSP environment surely you'd want it all centrally managed by
>> an admin so each device/server doesn't end up with 50 copies of
>> different versions of the same activity installed. It would be a
>> support nightmare, take up massive amounts of extra resources that it
>> need not do so and no doubt other issues that I haven't thought of
>> like issues with collaboration etc.
>
> The whole point is a learner/teacher can modify any activity at any time and
> then share that modification in a safe, sandboxed way, to other Sugar users
> (and perhaps back to us). No existing packaging systems seem to have any
> concept of this basic Sugar feature/goal :-( They all shout root, root, root
> and have install dependancies splattered across the OS like some midnight
> software massacre :-((
>
> I'd love to see some progress being made here, it's so painful to see this
> dialogue come up month after month (no offence intended).
>
> Apple I think are the closest I've seen, if you app needs some zany
> dependancies then it includes them in it's bundle (just like Sugar bundles).
> For the Mac users, it's just "Drag this application to your application
> folder." Done, end of story. For the worst application offenders (and there
> are some, usually some of the big corps who can get away with it) the user
> is asked for their admin password, but this always looks like shoddy, dodgy
> application development from developers who don't really know what they are
> doing on a Mac.

Yes the mac stuff is great if you want to install the entire gtk stack
or what ever its dependants are for every app you install, or you have
to use the OS libraries to keep your app small. Same principal yes,
but all macs ship with 100s of gigs or even terabytes of space. Not 1
gig like the current XO-1. The .xo distribution mechanism works great
for python apps because they're not compiled so you don't need to ship
dependant bits but if you wanted to support 8.2.x, what is SoaS 1,
what will be OLPC for the XO-1.5 and then SoaS-2 (or what ever they
want to call it) based on F-12 you'll end up shipping 4 binaries to
support it. That doesn't cover the Fedora mainline releases, the
Ubuntu and Debian variants all which could have different dependency
requirements and hence different requirements. If you ship just 1
binary that doesn't work in one of those environments how are you
going to support it? How are you going to debug it?

To be honest it doesn't bother me because I don't have to support it.
But from the 60 odd packages I maintain in Fedora I know the issues
that you have where people force install binaries from a later Fedora
release to try and get a newer feature and then try to report bugs
against it. It causes me enough problems that I've closed 3-4 bugs in
the last couple of days and I can tell easily due to package
versioning. Spread that across multiple possible combinations of
distos and it will be a nightmare to support if someone has to support
that activity. So go for it, but just be aware of the consequences.
There are reasonable work arounds. Yes, I read about the ability to
use pybank and verioning de-duping glorious filesystems to save on the
duplication of space and everything else. But the fact remains that at
the moment none of that cool shit is in place so yes, it would be
great, but it doesn't change the lack of developers working on it at
the moment and the fact that the ability to support the activity at
the moment on multiple different linux platforms exist so while rpm
isn't the perfect solution, as has been discussed numerous times
before, nor is the shipping of binaries in a zip file with no
dependency checking.

Peter