Application Repository (on Panda And Desktop), Real Discussion

[skeezix]

This topic comes up over and over, so lets beat it to death in one thread.

Rules of engagement -- please read the serious posts, and please try to be serious; don't add kruft and fluff, lets try to stick to the real core. Lets not think about pretty and "bottom of the nice to haves list", lets think about "core requirements" and "top of the list" stuff.. the real meat that it absolutely must do, and try to sort out if thats reasonable and can be done. If we can narrow down the _Requirements_, then we devs around can possibly attack it. ie: The dev cycle is to figure out what is needing building before figuring out the underlying tech..

If we actually get any useful information or kick off anything, I'll run with it .. at least log useful info to the wiki, or provide dev environment, or code it, or organize it, whatever. Or someone else could, I'm not intending to step on any toes, just thought I'd try and see what we can come up with


Initial ideas for discussion --

For my part, let me toss out my thoughts on an "application repository." ie: First we must define what it is, and what it is not, so that discussion has focus.

1) It is not to be an application store; that is a level of complexity we are not yet ready to deal with I think, and more realistically can be dealt with by developers wanting to go that route. (ie: They can already lock to an SD, and we'll find out down the road if theres some unique-ID that can be queried from the device, and so on. Could be treated like any other desktop OS at this point.) So lets skip this.

2) The Repo (and thus we are Repomen!) must be able to offer downloads of applications (ie: or links to the downloads for when kept on other servers.) (Worrying about versioning and backup copies and so on is all on the nice to have list, so we needn't worry about it up front.)

3) The Repo must be able to manage ratings and categorization hints. I actually see this as one of the prime functions, and also a big challenge.. given there may likely be many repositories of different construction, how does one manage ratings and categorization consistently? See below.

4) The Repo can be populated by users/developers entering info into a tool, uploading files or providing links, and/or feeding in the PXML to pre-populate a lot of the fields. ie: Presumably the tool should allow the repo to be maintained byt the users and developers, not some central agency.

5) The Repo tool should be able to request uninstall of an application as well (the implication of (2) and (4) is that zip files of applications are compatible to all devices and that we formalize installation and uninstaltion, be they including well defined data files, scripts or requests to apt-get etc..)

ie: That the primary functions of "app repository" are:

- browse,
- rate/comment,
- install (with basic options perhaps, such as warning, license review). Not including dependancy fetching, can leave that to underliing mechamism.,
- uninstall.

Later we can discuss nice to haves such as
- on device chat
- scoreboards/leaderboards
- match finder, etc
This is all 'complex' to organize and depends on a base of applications needing it and dev involvement and so on and so forth.. worry about that much later! Leave the frills out of discussion for now (though perhaps feal free to mention them so they can be tallied, but lets not discuss them too much)

Summary --

In a way, downloads and categorization can already be done using EDs fine gp32x file archives. I don't know if it can do formal ratings, but it has a comment section.

So an app repository really is offering supposedly easier download+install and uninstall lifecycle, and maybe a handy rating system and browser.

ie: WE'RE REALLY TALKING ABOUT AN IMPROVED DOWNLOAD SITE, and FORMALLING APPLICATION INSTALL/UNINSTALL.

Unless I'm missing something (which is highly possible givben my limited sleep

The comparison to "app store" on iphone, the upcoming RIM store etc and so forth are off in a way; those stores are 'neat' only because those devices have not had such a thing before; it is wiser to compare to "portals" for Palm, Pocket PC, PSP and other devices, where we can see more or less what we already want -- the ability to download applciations direct to panda. But since "app store" is such a hot thing in other devices, I think it is on peoples minds.. they wantsit!

Interface
-----------

Usable from Pandora? A lot of people would like this, and certainly it is desirable.

Usable off the Pandora (desktop, laptop, iphone, whatever) -- also very desirable. Some may want 100% of one form or the other, but the reality is most people would like both -- when lieing on the couch, suck apps right to their Panda; when at work or near a laptop or wanting to mass-leech or quickly brows large categories, using a big machine might be the way to go.

As such, the _interface_ strikes me as best being a tight little web application, which happens to include a tight little CSS or mini-front end for handhelds (pandora or otherwise), and a beefier front-end for big machines. (Could be same functionality, but it doesn't have to be.)

Being a web application sometimes suck and sometimes works .. and in this case I think it would be a win; ie: numerous browsers will already be available for the Pandora and most other machines, be it Firefox or Konquerer or whatever, so that takes care of the GUI frameworks; we then just have to provide the application and storage and so on, and being a web app.. its something a lot of people can help with.

Anyway, thats my suggestion, but feel free to make others.

If we go the route of a non-web front end, then we run the issue of having to build multiple clients -- one for the Pandora (which could be many, depending on what OS distros the user chooses.. some might have X11, some might not, some might be KDE or Gnome or neither, and so on.) Further, you have to worry about people wanting to download on their phone, PDA, netbook, desktop or laptop, so might just end up writing a bunch of clients. (Which might be a PITA, or maybe not so bad if you do it cross platform as a python/perl/whatever script... but again, thats for discussion.)

Backend
----------

As mentioned above, I see the tool as several parts ..

1) Content browser honuring categories, ratings, and so on
2) A tool to manage download and installation of applications
3) A tool to manage already installed applications and allow removal of them
-) I am not counting here the ability for installation of applications to ask questions and preferences, but maybe that would be a nice to have down the road; ie: to ask about ROM paths say, or when unistalling to ask about removing game save files, and all the usual stuff

In BSD and Linux-land we already have many fine package systems (and I use the term loosely, as most are total crap like RPM and even .deb .. they work, but they're not really pretty behind the scenes. But the world is complex, so they're turdy by necessity really.) I'm not sure if the device has settled on ports or debs or what.

One question that comes up is .. Angstom is one of the base Linux distros to be supported, and it is Debian based, making the apt system attractive for a lot of reasons. Of course, there is also Ubuntu as another distro that can be booted .. and Ubuntu is also Debian descended. Thats lucky. But people could run other distros or oeprating systems on the device, so that is to be kept in mind.

Anyway, an app repo tool for doing installs and not could just invoke apt-get install or whatever to actually manage files. This would probabyl be the best way, since we inheret many existing packages, and an already working install/uninstall system, solving many problems. If all the packages are finely tned to PAndora, we shoudl be able to avoid many of the problems these sorts of tools fall trap to.

In essence though, we're talking about an on-Pandora repository .. if files are downloaded from the (say) web tool on a desktop, the user would dump the files onto an SD card and then invoke the Pandora app repo client to work the files into the system (ie: behind the scenes invoking the apt-install and then consuming the PXML to file thigns into the application launcher, or whatever.) (I forget right now if PXML includeds install/uninstall hints etc, but it is a work in motion.. perhaps PXML shoudl only be concerned with launcher hints and so forth, but I digress.) IF the files are downloaded direct on Pandora web browser, then they could be dumped into an processed directory and worked on there.


Wall of text crits for 10,000!


Questions
-----------
1) Do you see the need for a new app repository, or is it just something people feal like they need becaue they haven't thought about it and realized they already have it?
2) Define app repository .. what does it mean to you
3) Do you see a need for it on one side or the other (pandora versus non-pandora); ie: I believe we need somethign workable from many platforms, but perhaps I'm the only one
4) How do you envision workflow .. for example, I'm envisioning someone browsing files the same sort of way as in ED's gp32x archive (see also www.palmgear.com for PAlm OS, say as well); once a user picks an application, they hit the download+install link, accept a license agreement and warning, and it downloads, installs, regiswters the PXML, and shows up in their launcher .. poof! Also, theres an uninstall tab or application that offers then a list of installed applications that can be ditched. But you may see something else.
5) What do you envision as being the backend page system? Something custom, or leverage the underlying OS mechanism (such as pkg, ports, etc)

What other questions should we be asking up front?

We're not worried about getting graphic artists yet, just scketchign out ideas. This might all go for not!

jeff

 

[AireTamStorm]

There's already been enough of these threads to tell the developers that Package Management is a requirement for the Pandora's success. I had started one a loooong time ago.

My Stance:
-I will host a repository for Japanese / multilingual input methods and utilities
-I will host a repository for POND updates
-I will support the full featureset of whatever package management system we use.

A package management system is, in my opinion, critical to the success of the Pandora. If we can leverage online connectivity with the OS for package management, communication, help, and make the experience of the handheld itself extremely community-oriented I believe this will take off from the Niche and launch into a fully capable and independent platform.

 

[azmodean]

A few things:

Custom solution: NO
There is no reason to try and reinvent the wheel here, as has been pointed out many times, there are actually repositories of linux-arm packages which we should be able to just use. Also there are many, many apps written for existing systems, not just clients. There are servers, clients (with many levels of user friendliness), and other utilities. For example there is apt-cacher for debian packages, you could leave it running on your PC and download all your packages "indirectly" through it. Any time you want to clean things up you could uninstall apps from your pandora, and subsequently grab them from the cacher without re-downloading them. This might not seem like much, but in fact it's a working solution that will function completely transparently once you set it up (I've set up a apt-cacher before, it's pretty easy) and it takes almost no additional work on the Pandora side of things to get it up and running.

The other thing to remember about using an existing system is that the servers at least will not be going through any debugging at all, they'll just be serving up pandora-specific packages, and the clients are also proven and just need to be ported, which would allow for a far faster and more stable deployment than coding a custom repository system.

If someone thinks they can write the perfect package management solution for mobile devices, more power to them, but it's just silly to push for a custom system for the Pandora unless there were a massive technical reason that it would be impractical to use existing, working solutions.

Web interface: ewwww
The pandora might be fast, but a modern web browser is still quite a hefty prerequisite. Just a quick sample, there's Firefox3 running on my system right now showing 170MB of memory usage through ps, and synaptic, one of the heavier package managers is also open and showing about 38MB of memory usage through ps. It's a bit tough to get a snapshot of apt-gets memory usage since it isn't resident in memory unless it's actually doing something, but I'm pretty sure it's lighter-weight than either of the other two.

Long story short, repository yes, but I don't see any reason to want to "design" a package management system for the Pandora, any more than I would expect someone to write a new OS for it. Isn't the point that it's a linux device that can leverage all the existing software instead of the developers/users having to write it all themselves?

 

[absolofdoom]

i just want to say one thing. I would REALLY like to see a few centralized repos - or even just one, and not a bunch of them. That's the main thing that made me sick of my n810. There's like 50 repos, and some packages work, some don't, some repos are down, some aren't, it's just annoying as hell. It didn't bother me when I had time to mess with that sort of thing, but school's keeping me too busy to spend 30 min trying to install something. Last thing I want is for the pandora to end up like that. Just my 2 units of currency.

 

[Mithander]

Here are a few of my thoughts for what they are worth.

As far as leveraging an existing repository (dpkg, rpm, apt-get, etc.) I don't think it's a win. They are not designed for removable storage, and it seems like that is all we will be dealing with. It would be great for the built-in flash, but if we keep it like the gp2x, then everything will be on the removable card, and then things can be a little tricky, and I think it's more work to get that to work then to write a simple package manager. It also creates problems for installing from a PC.

One thing that hasn't been talked about that I think is needed, is upgrading. I would like to know what packages I have installed, and which ones are out of date. Ideally a one button press upgrade all. I'm not sure if this can be handled with a web frontend.

What I kind of envisioned using was an application that was a front end to the gp32x file archives. It would install zip files in a standard way. (For example extract foo.zip into /sdio/installed/foo). Then it would be able to uninstall by deleting the directory. Scan for installed packages by doing an 'ls /sdio/installed'. Then from a PC, as long as you followed the same procedure by hand (put the zip in the correct place). Then it would 'just work'. I realize this is a bit simplistic, and there are likely many holes where I havn't thought it through.

Also, it seems like there are 3 ways a package may be installed. Pandora only (via wifi), Pandora + PC (Pandora connected USB) and PC only (writing to sdio card). I'm may be missing something here though (one may be the same as another, or one is not possible). But if not, I think we want to address all 3.

 

[PoisonedV]

I agree with previous sentiment- there needs to be a concentrated effort on one repository.
Also, to make things more modular from the start, I suggest breaking everything off into 2 categories: Applications and Games.
if you want to implement scoreboards or leaderboards or achievements or any social-networking game features, those would really only be suited to games, and then you would have to do a complete overhaul. this is extensible to the whole thing, it's probably a good idea to have a complete plan set up before you start

 

[MaxSteiner]

Ok, Im not really qualified for this discussion, and I know this programs hardly a big secret or anything, so feel free to mock me or whatever....

But couldn't we just use DC++?

Its open source, already exists in a Linux version, works incredibly well (the swarm download is a dream come true) and all you'd need to do is have a hub for Apps, and a Hub for Games.
Added to that, unscrupilous people could set up their own ROMS hub completly unconnected to Open Pandora and everyones happy.
Pretty easy to add custom content on the board too
And aslong as people just have it running in the background whenever they're online we should get decent amount of coverage (proivided they have their SD card with their fileshare in there.

I use this program all the time and I love it (mostly because it reminds me of BBS back in my Amiga days) I've got some friends who can't figure it out... but honestly I think thats because they have brain damage .
(That said no idea how it would handle Wi-fi of a portable device, might have to use passive mode on it or something?)

http://dcplusplus.sourceforge.net/
http://en.wikipedia.org/wiki/DC%2B%2B

 

[PoisonedV]

Ok, Im not really qualified for this discussion, so feel free to mock me or whatever....
But couldn't we just use DC++?

Its open source, already exists in a Linux version, works incredibly well (the swarm download is a dream come true) and all you'd need to do is have a hub for Apps, and a Hub for Games.
Added to that, unscrupilous people could set up their own ROMS hub completly unconnected to Open Pandora and everyones happy.
Pretty easy to add custom content on the board too
And aslong as people just have it running in the background whenever they're online we should get decent amount of coverage.

I use this program all the time and I love it (moistly because it reminds me of BBS back in my Amiga days, I've got some friends who can't figure it out... but honestly I think thats because they have brain damage.
(That said no idea how it would handle Wi-fi of a portable device, might have to use passive mode on it or something?)

way too unwieldy... none of the custom features... definitely not the direction you would want to go
will work fine for roms though ;D

 

[MaxSteiner]

Ok, Im not really qualified for this discussion, so feel free to mock me or whatever....
But couldn't we just use DC++?

Its open source, already exists in a Linux version, works incredibly well (the swarm download is a dream come true) and all you'd need to do is have a hub for Apps, and a Hub for Games.
Added to that, unscrupilous people could set up their own ROMS hub completly unconnected to Open Pandora and everyones happy.
Pretty easy to add custom content on the board too
And aslong as people just have it running in the background whenever they're online we should get decent amount of coverage.

I use this program all the time and I love it (moistly because it reminds me of BBS back in my Amiga days, I've got some friends who can't figure it out... but honestly I think thats because they have brain damage.
(That said no idea how it would handle Wi-fi of a portable device, might have to use passive mode on it or something?)

way too unwieldy... none of the custom features... definitely not the direction you would want to go
will work fine for roms though ;D


(Honestly thats the main thing I was thinking off hehe)

 

[cb88]

modify apt-url to ask for a destination.... web interface done a clone of the brand new debian web package interface might be nice (they are implementing a web package system with screenshots from what i gather)

write a script that converts pxml to deb..... not too hard deb can install interactively asking for a destination drive ever installed a firewall app or some other app in debian? you get a pop up... deb is the answer

even though most deps will be bundled there might be some that it is just impractical so you can always rely on deb as a fallback

checkinstall is AWESOME!!!!!

besides from what I understand angstrom is debianlike... (ipkg i think is an apt frontend) so ... debs are the pretty natural choice they aren't THAT hard to understand especially with checkinstall

 

[Hooka]

First off, skeezix you've got some good ideas in there

and Mithander, you're on the right path with the 3 there... although I'm unsure how the pandora appears to a pc when plugged in via usb (might be mass storage, might be usbnet, might be something else, atleast it probably won't be something closed and proprietary...) depending on how it is setup, there is potential...

Just to throw in my little nuggets (not sure if they're gold or just stink nuggets, but I'm sure you'll choose whichever of the two you prefer), I dunno about the whole web browser frontend for a repository... makes me think cnr, which I guess isn't bad, but at the same time seems lacking to me.

I would like to see it also handle adding roms/game data/music/videos/etc. to the proper location (say the packages have a section to add roms from a folder into the proper folder for you)

With the multiple storage media, I still want to suggest using dynamic linking, but have 2 different classes of libs (one that belongs on the NAND, and the other that should just be installed on SD). This would allow us to have the repository to update firmware (download everything first then install after checking to ensure pandora has enough power, etc. ofcourse ) and manage static libs, apps and games on SD. There would need to be careful attention taken by the package manager to make sure that any SD card containing an application/game requiring a lib had it available. This would potentially provide 2 copies of the lib (one on each inserted SD) in certain cases, but if you removed one or the other you could still use it effectively... I'm not sure if you could make some sort of symlink in the lib dir that could be used to add a directory of libs on the sd card into the libs dir, but some form of trickery like that might work...

I know some people see this as being counter productive, but at the same time I see this as a way to simplify the pandora experience in the long run in a similar fashion to how the pandora itself was conceived, by taking the personal experiences of the community members to create a highly optimal solution.

As a final note, this is just my personal thoughts on this topic, and I would be willing to help make this a reality if it is wanted

 

[skeezix]

Like I said up front, perhaps I'm way off base..

Consider -- and for those who didn't read mny post, I never suggested writing a new package management system; the existing ones aren't great, but they're there and we haven't the manpoewer to redo the world So please go read my post Also note.. peopel tend to 'knee jerk' in this arena.. yes its been brought up before, and yes lots of smart people commented. But nothing has come of that, so I thought I woudl try to channel things this time and focus. Maybe I shouldn't bother and let the chaos continue, but hres to trying!

To everyone else -- for me, one of the requirements is that it works on and off the handheld; ie: Sometimes you'll not have your panda with you, or sometimes you won't have wifi, or sometimes you'll want the bigger realestate that your laptop or desktop offers that the Panda doesn't, and so on. Maybe its my PDA bias, and iphone bias, but I can guarantee.,. in traditional usage people tend to do 50/50 "All things being equsl (handheld just as connected as non handheld), so generally want it on both sides. (Consider you're at work .. no one here can say they've never browser gp32x forums while at work, right? And your panda isn't with you, or you don't have network access for it .. quite common in corp environments!)

So for instance, a Linux based solution for frontend.. all well and good for us geeks, but for average joe.. not a great option. (But maybe the pandora average user runs Linux? I doubt it.)

Hence my suggestin for a web based solution (which does not necessarily mean heavy duty with needing FireFox either.. could be Lynx based for all we care

AireTamStorm -- yes, we all agree; this is not the point however. We're talking about the layer on _top_ of the package management system, where peopel can browse and request install of apps (which natraully uses the package management system.. read me post

azmodean -- never suggested a custom solution; I'm trying to come up with 'requirements' here so that a solution can be found or built, amd if you read carefully.. never suggested writing a pkg manager

maxSteiner -- I think a Linux oriented solution might be a not good idea, though it is awfully tempting for a lot of reasons. Still, I'm trying to keep with the idea of letting people browse while at work, say, without needing a liveCD

Or maybe I'm putting too much emphasis on the client working all over the place and am strongarming too much

*shrug*

As to the good points so far .. we definately need well defined repositories, but IT hink that will not be a problem. We've got the resources here already and all the devs and us are onboard with that.

jeff

*hides*

Should I start a poll to ask people about on/off handheld, so we can try to nail that down? That is a game changing question.

Edit: I suppose I should clarify even more aspeople are PMing me and still not seeing what I think we're talking about .. ie: On the iPhone (and related), there is Installer.app -- that is what we're talking about here, really. It useds apt to install packages on the phone itself, but it offers the tool for browsing and fetchign them down. (And yes it works well and is iphone only.)

 

[Klepto]

IMHO...

An on-Pandora solution is essential, a desktop version is desirable but secondary. How could the Pandora be taken seriously as a mobile computer if you need a desktop to install software on it?

A web interface makes very good sense to me but there are those here who don't seem to like the idea. Perhaps you should provide a command line client or a well documented network interface and then others can write 3rd party GUIs for it. Taking this further, it may be an idea to differentiate between user and contributor interfaces, with users getting pretty eye candy and contributors/admins using a more powerful but visually less inspiring web interface.

Please make security a central consideration. Allowing people to freely upload software without any vetting process is asking for trojans and other nasties. While this worked for the GP2X and GP32 neither of those devices had the same kind of internet connectivity as the Pandora, I imagine many Pandoras will spend most of their time connected to the internet.

 

[sebt3]

First of all : Thanks Jeff for bringing this topic the right way, maybe we will answer it together

Before starting I have to say :
- I wont bring man power to this project as I don't have time to write a single loc since a long time.
- I'm a debian user for nearly 10 years so I'm biased

As you pointed out no existing package management system match our need : there are still people that is not connected to broadband, and there some that hate wifi and will still use the pandora as a toy.
I you already maintaint a host using a package management without a connection to the net. What a mess. Apt handle it correcly (generate a list of download you have to fetch manually) but this is not fun nor easy.

So a solution only based on apt/ipkg is not workable at all.
To maintain a usable system

Developper need to forget about dependency as each package have to bundle all depency. So the main OS (the one in the flash have to be stable) Nobody want to see discution on these boards like this :
"you program dont work on my pand"
"run ipkg update"
"done and now it fail because of..." (new dependency problem)
So the base OS should be update once in a while (each 6 months or so, but don't match ubuntu release cycle )

Next. What do we need/want ?
Those disconnected still need an easy way to download app. (the pandora archive is good enouth for the job)
Those connected will prefer a front-end (on the andora1: ) to the pandora archive that will download and unpack on th SDCard.

So basically we have 2 front-end. So the back-end should be aware of this position.

I dont know the state of the pandora archive code-wise, but the web front-end is ok for me. We can have screenie there and user comments. That perfect for me.
Another solution could be opendesktop. But I'm not sure that we want that all our stuff is managed by some unknown company even if this one is trusted by other communities.

So basically, we are talking about :
- Editing the pandora archive so it could provide information to the pandora frontend. XML come to my mind (hey, we will have an XML parser just under our hands) And It should not be that difficult to provide XML instead of xhtml...
- writing an easy to use frontend using these XML files that unpack the archive nicely on your pandora.

Even if it sound easy in this post, I agree that this is not a quick task that could be handled by ED alone in a week. And I agree with you ED have more important thing to do than this. So we should do it ourself.

Jeff, did I understand correctly ?

 

[skeezix]

Regarding dependancies, thats a tough one, but my thought has been a "lowest common denominator" approach .. ie: There shoudl hopefulyl be some common set of libs between the various OSes built for Pandora; unlike a fat desktop distro we can' tinclude 15 versions of every library, but it might be nice if the distrods were built to include a common subset of key libs, that applications could "depend on". (There is some discrepency here, ie: Gnome versus KDE and so forth are big ones, but I'm more worried about libc and libSDL and so forth.)

ie: It might be "too big" to include a tonne of dependancies in each project (not to mention duplication), but more to point.. there wil be at least 2 distros, if not a few more. (Angstrom the defaul and Ubuntu as supported. But folks are at least working on Gentoo if not others, though we'll have to see if peopel stick to one, both, or all sorts.)

As such, I think it best to include "minimal" dependancies in each aplication, but try to standardize what is available to most applications.

--

For backend, I still think depending on an existing package system is the way to go (ie: who has time to write an all new one?), depite their flaws. The trick is to provide as you say a nice front end to make all of this easy.

Maybe I'm over-thinking it.. perhaps rolling together an existing front end with an existing backend, and making it Pandora-only is the way to go.. provided the mechanisms (xml etc) are documented. Then later more frontends coudl be thrown together by whoever had their scratch eeding itching.

--

I wouldn'y say those connected would prefer a panda-side client; they may well when connected with pandora, but if they're at work or the like, they might just want to queue things up for later for the pandora, or download straight out while at work and then go home (maybe they have no reliable connection at home even at all?)

--

Decisions decisions..

To wit I am not saying I will write anything either (I might, I might not), but lets see what discussions we can have

jeff

You know, making it pandora-side-only would certainly make it 'easier' to bootstrap a project

klepto -- palm/etc have been doing it for years with a dependancy on a fat-machine, but you're right.. pandora is much more, being like a netbook. But why worry about perception.. worry about what you want and need, not what your gutt says. But I think tyou are probably right.

 

[sebt3]

ie: It might be "too big" to include a tonne of dependancies in each project (not to mention duplication), but more to point.. there wil be at least 2 distros, if not a few more. (Angstrom the defaul and Ubuntu as supported. But folks are at least working on Gentoo if not others, though we'll have to see if peopel stick to one, both, or all sorts.)

Oups sorry, I should ave misreaded your post sorry. I was only thinking about the main distribution. Because it's the only one that matter in-fact.
There is a large will for a debian arm + custom distrib, and I will be on this bandwagon myself
I think tht developper should only provide :
- a pandora package (with the pxml thing)
- source-code if they want.
Then the "alternate distro managers" will have to package themself for their beloved alternate distro. (If the licence allow it )
For the binary(ies) in the package, ED said that we should dynamicly link to the libs in the flash and statically link for the rest.
Anyway as the OS on the flash will be (ultimatly) community-based, if ther is a need for a lib in the flash, then the next flash revision will contain it

For backend, I still think depending on an existing package system is the way to go (ie: who has time to write an all new one?), depite their flaws. The trick is to provide as you say a nice front end to make all of this easy.

Maybe I'm over-thinking it.. perhaps rolling together an existing front end with an existing backend, and making it Pandora-only is the way to go.. provided the mechanisms (xml etc) are documented. Then later more frontends coudl be thrown together by whoever had their scratch eeding itching.

I think a power-full enougth back-end could be written quite fast using the source of the pandora archive.
For the front-end, once the back-end is done. Give a good doc on how it works... Wait&see.
6 months later, you have a winner

You know, making it pandora-side-only would certainly make it 'easier' to bootstrap a project

I didn't get you there. (my english is limited...)
I actually enjoyed most of your work on the palm/os so I'm sure you're able to manage a handfull perl scripts.
(I readed that you didn't promise a loc on this discussion h34r: )

/me hope to be helpfull

 

[ShyGuy]

I know this is a popular idea among hardcore Linux users. I was attracted to the idea myself originally... but it seems to me that most of these ideas overly complicate what is essentially a game system, with a gamer's OS. Have any of you guys actually read the PXML file spec? There's no way you could accomplish many of its features as transparently with a package management solution - one which is probably better suited to non-removable data storage.

Don't get me wrong. I use apt-get all the time and I love it. I just think it's the wrong direction for the Pandora.

 

[Hooka]

sebt3: I was thinking the same as you, seeing as alternate distro's are supposedly going to run off of SD, why not aim at supporting only angstrom with the package management discussed here, as you'll be booting the entire OS off of the SD, there is no longer the worries of needing to split the destinations (aka, the whole SD will be ubuntu's, therefore no limit of NAND size, but limit of SD size and apt-get will be updating SD contents )

Leave the beefier distro' to their own while trying to optimize and help Angstrom grow