On Mon, Aug 17, 2009 at 10:34 PM, Gary C Martin<[email protected]> 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 _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
