Package Manager Repos

[Tobriand]

Like has been said before, we are trying to keep this as simple as possible - Download app, throw it onto an SD card (or copy from another), done. No dependencies = no hassle.

That's where I see the problem. That means a nightmare updating the app. Users could be educated to get stuff from the repository and there's always the option of apt-file.


Why would that mean it's a nightmare to update an app? Surely it'd be easier if done as Squidge has said it will be.

The standard model of download to desktop from wherever the program is hosted, unzip to SD (maybe in device, maybe not) and just play has worked brilliantly for the GP2x - it's just a touch more complex than a very basic user can deal with.

Solution: build in access to the archive, and installation of programs, to the device itself. But all that means is something that downloads the archive and extracts it wherever the user wants it extracted. Updating software, probably, simply by overwriting (whether the SD is in the unit or not).

The only penalty I can see with that model is that no software will ever work automagically better than it does when originally released via library updates. But the corrollary to that is, of course, that no software will ever work *worse* than it originally did either, and I think that's what most of us want to hold onto.

Aside from saving a little space (probably amounting to ~40mb in the most extreme cases, I'd imagine), and performance boosts by updating a centrally stored library, what are the advantages of going with a different route than the one proposed? Because neither of those is, in my opinion worth the potential difficulties when people try to install things in the way that around 30000 of us are now used to!

 

[Megamixman]

For example, someone removes one of the applications that uses the library, deletes the library assuming it's no longer needed, and finds some other programs no longer work. Or they copy an application from someone elses SD card (or downloads an app from the web using there PC as they don't have Wifi), forgets to download the library, and gets frustrated when they find out it doesn't work. All these equate to bad user experience.

Again this is where a good package manager kicks in. It wouldn't uninstall the dependency since it knows that it is needed. The GUI could make a prompt asking whether you really want to uninstall it and if so X Application needs to be uninstalled as well. Although Pandora will be running linux, it is basically running a specialized distro like maemo. Meaning people can setup packages for most everything.

People tend to rely on GUIs. As long as the GUI interacts directly with the package management system, most problems are eliminated. I'm not saying this is perfect, but neither is the static linking.

In terms of savings, it may not seem like much on small apps, but lots of good linux apps depend on Gnome or KDE libs, both of which can take up significant space when statically linked to each and every single app that depends on them.

What I'm trying to state is that, static linking works, but it is also highly restrictive. Maybe not in the short term, for small apps, or media based applications where the data size far outweighs the app size, but that neglects people who have a small amount of data and a large app base.

I think the other problem might just be that people haven't seen a exceptional package management system, which is why I recommended pacman from Arch Linux. Go check the forums and wiki. The system is extremely simple, flexible, powerful, and is the foundation for Arch's rolling release system. It has full dependency management and with the exception of a few times when a package has an error, it is basically flawless.

 

[Orkie]

But what about copying between SDs as Squidge said, or people who don't have access to the Internet on the Pandora itself?

 

[sindbad]

I never tried arch. However, a rolling release system doesn't seem a good thing for the pandora. It's best if the developer of a certain app/game can say that it will work with version X of the pandora distro, since not everybody will keep their system up to date.
That's partly why I'm partial to apt. And also because it has served me well for quite a while.

But what about copying between SDs as Squidge said, or people who don't have access to the Internet on the Pandora itself?

There's apt-file for that. An online service could be made where when you download an app, you get all it's dependencies (you essentially download an archive with debs in it). You put the thing on the pandora's SD and tell a gui about it. The gui then sicks apt-file on the debs in the archive and installs what's needed. Full dependency checking and all.

Sharing apps that may have different version is not healthy.

 

[AireTamStorm]

Like has been said before, we are trying to keep this as simple as possible - Download app, throw it onto an SD card (or copy from another), done. No dependencies = no hassle.

On one hand, I see the sense in your argument for ease-of-use. Additional benefits include:
-Using libraries guaranteed to work (no version change conflicts)
-Monolithic executable makes it easy to copy
-Similar experience to that of installing stuff on a GP2X

But we're talking package management here. All installation should be done by the package manager, not manually by the user. The package manager will install the program and fetch the libraries if necessary from the SD card, the internet repository, or other external storage. If a user tries to delete a library in a package manager, the back end checks to see if stuff depends on it. Package management is designed to make dynamically linked libraries and the packages that depend on them easy to install. If we had nothing but statically linked binaries, why would we need a package manager anyway? Huge, statically linked binaries are something I hated about the GP2X.

If you're talking ease-of-use, you shouldn't have to connect the device (or a storage medium for that matter) to a separate computer in order to install something in the first place. I, for one believe the Pandora is best designed as a -completely- self sufficient device, rather than one dependent upon other hardware.The thing has WiFi, you should be able to get on a hotspot, download a package (and its dependencies as needed) and install them to internal flash or an SD card, all without a computer.

If you really want SD card installation ease-of-use, pop your dependency packages into a zip file along with your package. The package manager will look for the libraries in its database, if it cant find them, it installs yours. That way, both parties are happy, because we save space on shared libraries, can update those libraries, and you get a complete, hassle free package.

Your thoughts?

 

[Orkie]

If you really want SD card installation ease-of-use, pop your dependency packages into a zip file along with your package. The package manager will look for the libraries in its database, if it cant find them, it installs yours. That way, both parties are happy, because we save space on shared libraries, can update those libraries, and you get a complete, hassle free package.

Having these binaries that are *potentially* semi-statically linked (yes, you can mix static and dynamic in the same binary) means that a fancy download GUI can grab the package or you can copy it over manually. Having dependency tracking means as you said, having to download dependencies manually and if you've ever tried to do that on the Debian website it is a pain.

We have been considering this for Open2x for about a year now, and it is the best solution anybody has come up with. I can tell you for certain that nearly all GP2X applications use no more than SDL and its helper libraries and libc. This is likely to be the case with the Pandora also, so actually only very few things will have any kind of static or bundled dynamic linking (and like I said, you can link for example SDL etc. dynamically and libwhatever statically).

 

[Megamixman]

If you really want SD card installation ease-of-use, pop your dependency packages into a zip file along with your package. The package manager will look for the libraries in its database, if it cant find them, it installs yours. That way, both parties are happy, because we save space on shared libraries, can update those libraries, and you get a complete, hassle free package.

Having these binaries that are *potentially* semi-statically linked (yes, you can mix static and dynamic in the same binary) means that a fancy download GUI can grab the package or you can copy it over manually. Having dependency tracking means as you said, having to download dependencies manually and if you've ever tried to do that on the Debian website it is a pain.

We have been considering this for Open2x for about a year now, and it is the best solution anybody has come up with. I can tell you for certain that nearly all GP2X applications use no more than SDL and its helper libraries and libc. This is likely to be the case with the Pandora also, so actually only very few things will have any kind of static or bundled dynamic linking (and like I said, you can link for example SDL etc. dynamically and libwhatever statically).



Again look at pacman. The repos for pacman are simple just folders on the web. They contain the packages and a db file that has info on all the packages, descriptions, version, dependency info, etc. Pacman keeps a local copy of this db ( very small files for Arch the total size of all the db's is ~ 1mb and there are 1000's possibly 10,000's of packages) and then uses the info there to download the dependencies. Of course this means someone has to manage the repos.

As for libraries, I'm pretty sure Pandora will use a lot more. Pandora has specs that are far better then the Nokia tablets and look at what they can and do run. People will probably run full Desktops on Pandora the same way people do on the Nokia Tablets.

If people don't want a full linux ditro with WM etc, then they don't have to. Just install the base system and run games. If you want a WM,etc. tell the package manager to grab Gnome or KDE or w/e and it takes care of installing it.

 

[Orkie]

Yes, but why force people to use a package manager for everything? I am not anti the idea of having apt or whatever (I had both dpkg and ipkg running on the GP2X), but having dependency tracking for game seems daft.

 

[sindbad]

Again look at pacman. The repos for pacman are simple just folders on the web. They contain the packages and a db file that has info on all the packages, descriptions, version, dependency info, etc. Pacman keeps a local copy of this db ( very small files for Arch the total size of all the db's is ~ 1mb and there are 1000's possibly 10,000's of packages) and then uses the info there to download the dependencies. Of course this means someone has to manage the repos.

Excuse my bluntness, but I don't think pacman is a good idea.
Apt has also been tested much, much more and works very similarly. Same thing with repos being directories and small db files with lists of packages and versions and everything.
Not to mention the debian armel repos could be used, which can't be said about the x86-only arch ones. Compilation on the pandora is undesirable.

Yes, but why force people to use a package manager for everything? I am not anti the idea of having apt or whatever (I had both dpkg and ipkg running on the GP2X), but having dependency tracking for game seems daft.

There won't be any dependency tracking for anything. Games can simply provide an archive with all the dependencies in neat little debs (or just the game .deb for users with fast internet access). When a user installs a game from a multi-deb archive, the package manager decides what to install from where depending on versions.

Best from both worlds. It just requires a nice and smart graphical interface to apt.

Static linking is not only a very bad idea and inefficient use of the little resources at hand, but also evil.

 

[Orkie]

Well I give up, I'm not going to win this, you clearly know best - the fact that static linking is evil proves it!

 

[sindbad]

Well I give up, I'm not going to win this, you clearly know best - the fact that static linking is evil proves it!

Of course!

The thing is, the pandora can and will do much more than the gp2x. There will be a lot of software that needs extra libraries and much of these are shared between apps (kdelibs or other such things). A good package manager should, well, manage this.

I think it's best if developers provide their apps in 3 ways:
- just the app with no dependencies (a .deb) for users with good internet
- the app with all dependencies (an archive of .debs) for users with not so good internet
- everything statically linked for users that can't let go of the past
Toolchain would need to handle this.

Everybody's happy and users can manage their software in any way they like.

Does this make sense?

 

[Squidge]

If people don't want a full linux ditro with WM etc, then they don't have to. Just install the base system and run games. If you want a WM,etc. tell the package manager to grab Gnome or KDE or w/e and it takes care of installing it.

How about this then: By default there is no package management, binaries are statically linked, etc, etc. However, if you want to turn your Pandora into a full desktop with WM and Gnome/KDE etc, then you download a setup package for that which installs a package manager along with other crap, er, stuff.

Therefore people used to the GP2X or just want a simple life with there emu's and homebrew games/etc get exactly that. Those who want the works have to learn about package management, as the system has just got a little more complex.

 

[Blah]

Package managers aren't evil. Throwing around random zips with random static and dynamic dependencies and expecting users to be able to sort it out is. Even linux noobs have no problem using a good package manager, and for those few who are unable to connect their pandora directly to the internet, they can just plug in to a PC and leech away.

 

[Tobriand]

Random zips are going to be around anyway, package manager or no. You're forgetting datasets and roms, skins and media, and anything else that's beyond a package manager's demesne. Which poses a question: what's more complicated - installing your program by one means and then installing it's data by a completely different one, or installing everything via the same route?

And where did all the talk of evil come from anyway?

 

[Megamixman]

Excuse my bluntness, but I don't think pacman is a good idea.
Apt has also been tested much, much more and works very similarly. Same thing with repos being directories and small db files with lists of packages and versions and everything.
Not to mention the debian armel repos could be used, which can't be said about the x86-only arch ones. Compilation on the pandora is undesirable.

Debs are fine. I was merely using pacman as an example. Honestly though, package management on a rolling release system is far more crucial then on a versioned release. So although debs have been around longer, i wouldn't say that they are necessarily better then pacman, other then that fact that you can use debain armel debs. Also, you don't HAVE to compile on pandora. You can cross compile which I believe is how the debain armel packages are made.

How about this then: By default there is no package management, binaries are statically linked, etc, etc. However, if you want to turn your Pandora into a full desktop with WM and Gnome/KDE etc, then you download a setup package for that which installs a package manager along with other crap, er, stuff.

Therefore people used to the GP2X or just want a simple life with there emu's and homebrew games/etc get exactly that. Those who want the works have to learn about package management, as the system has just got a little more complex.

The problem with that is Pandora isn't marketed as just a gaming platform. Look at the OpenPandora main page. It is marketed as a PDA, MID, Internet Device, and a Portable Gaming device. So what do you say to the likely plethora of people who are going to get it for all those purposes?

Secondly, there is no real need to make it so that people have to learn package management. Most everyone is already used windows based setup programs. Packages are basically the same thing. Dependencies can be grouped in together and the package manager would intelligently use them, or go to the online repos. This is trivial and is implemented in most major package managers. Integrating the package manger part way in is where things would get tricky.

Random zips are going to be around anyway, package manager or no. You're forgetting datasets and roms, skins and media, and anything else that's beyond a package manager's demesne. Which poses a question: what's more complicated - installing your program by one means and then installing it's data by a completely different one, or installing everything via the same route?

Yes, but that is data. App != Data, well ok it is, but you get my point. There is an abstraction between executable data and storage data. Rom's, skins, media, are storage data. They don't directly do anything and you lose nothing by not having them there. Libraries are different. You can have problems if they are there when they shouldn't be and if they aren't there when they should be. Since it looks like Pandora will be running its own linux distro, why not structure it like a linux distro and have a home directory? You don't need to have users, but just that abstraction is enough. People who write linux code are already use to this idea. People who write code for Pandora are more then likely to use a linux development environment, so the same would apply to them. That abstraction would be transparent to the user in the end either way. Those who want to dabble into more advanced things can, those that don't , don't have to. It allows for well structured system, eliminating a lot of headaches.

 

[AireTamStorm]

If people don't want a full linux ditro with WM etc, then they don't have to. Just install the base system and run games. If you want a WM,etc. tell the package manager to grab Gnome or KDE or w/e and it takes care of installing it.

How about this then: By default there is no package management, binaries are statically linked, etc, etc. However, if you want to turn your Pandora into a full desktop with WM and Gnome/KDE etc, then you download a setup package for that which installs a package manager along with other crap, er, stuff.

Therefore people used to the GP2X or just want a simple life with there emu's and homebrew games/etc get exactly that. Those who want the works have to learn about package management, as the system has just got a little more complex.


That defeats the purpose. The package management is there for the ease of use. If there is a good backend, GUI, and integration, the package manager will be by all means easier than the alternative. Sure, people will have to copy ROMs as they did in the past-
(or get them over WiFi!) but they don't need to worry about installing and maintaining programs. The package management helps with updates, installation and removing stuff. We're not talking command line here.

I guess my main point is that a package manager should be designed to make it easier than copying files to an SD card. We have an internet connected device. About the only reason SD card copies were defacto on the GP2X was because there was no internet access!

It would be quicker and easier just to use a preconfigured PM and have a little menu option saying "Hey, look what I can install for you off of gp32x.de's Repository!" "Here's an SNES emulator!" "Here's a video player!" "Here's firefox!" and check all those cute little checkboxes so that it fetches and installs ALL OF THEM FOR YOU, at the same time, to the SD card. I do not see how this is harder than getting on a computer, open a web browser, going to a web page, search for what you want, download the files to your PC, copy them to an SD card, put the SD card in the Pandora, and run them from there.

Disclaimer: This is MY opinion, and MY opinion is that the Pandora should be a -completely- self sufficient device that does not depend upon other computers to do -anything- by default. Your opinion may differ and I definitely respect that.

Lastly- we should all take into account that the votes on this poll say what (at least a small part of) the community wants.

 

[Esn]

I... I've never used Linux, and I don't understand what any of those choices mean.

I just hope it's easy to use. :unsure:

 

[AireTamStorm]

I... I've never used Linux, and I don't understand what any of those choices mean.

I just hope it's easy to use. :unsure:

A Package Manager is a program that goes out and installs programs for you. It will install a program and any other programs that the one you want needs, automagically and easily. APT, Portage, and YUM refer to three of the most commonly used package management systems in Linux distributions today. APT being lighter weight, Portage being optimized, YUM being powerful yet somewhat bulky (theres not much that YUM can do anymore that APT cannot do faster).

"As long as it has a GUI I'm fine" would likely be your choice. You don't care what backend (the behind-the-scenes people) is used as long as it is practical and EASY to use. GUI stands for Graphical User Interface. It basically means you have a little window that shows up on the screen that makes a program easier to operate by giving the user visual choices rather than typing commands into a command line. You can search "SNES emulator" or "Arcade game" and it would find games based upon your search.

So the question you need to ask is: "Would I like a program to go out and fetch programs (emulators, media players, and applications) for me, or would I like to go out and find them myself?". The end result is the same, you get your emulators / games / media players. The difference is how you get them.

 

[pupnik]

If people don't want a full linux ditro with WM etc, then they don't have to. Just install the base system and run games. If you want a WM,etc. tell the package manager to grab Gnome or KDE or w/e and it takes care of installing it.

How about this then: By default there is no package management, binaries are statically linked, etc, etc. However, if you want to turn your Pandora into a full desktop with WM and Gnome/KDE etc, then you download a setup package for that which installs a package manager along with other crap, er, stuff.

Therefore people used to the GP2X or just want a simple life with there emu's and homebrew games/etc get exactly that. Those who want the works have to learn about package management, as the system has just got a little more complex.


This is good and bears repeating.

* Non-linux Ppl who just want to play games/emus will appreciate a system that boots fast and gives them a monolithic program selector menu with easy-install of games/emus.

* Linux ppl will want to be able to run something like a full desktop debian distro on the device.

Get the first one working, and make sure that design decisions early on don't cripple the second. I'd prefer to see debian armel with matchbox/hildon for the UI.

So this dual-modeyness would either entail

* Dual Boot (one safe, stable pandora partition, one partition for alternate full blown linux distro)
* Boot to console with monolithic graphical program launcher, then make program launcher able to INIT 5 to start a full blown X.

Whatever route, the 'full blown linux' version should use a standard ARMEL distro. Debian ARMEL with matchbox/hildon on-top should be looked-into for this. Leverage that nokia / maemo software.

 

[Megamixman]

QUOTE
This is good and bears repeating. * Non-linux Ppl who just want to play games/emus will appreciate a system that boots fast and gives them a monolithic program selector menu with easy-install of games/emus.* Linux ppl will want to be able to run something like a full desktop debian distro on the device.Get the first one working, and make sure that design decisions early on don't cripple the second. I'd prefer to see debian armel with matchbox/hildon for the UI.


No matter what, Pandora is going to be running Linux in some form. A full blown distro does not mean it HAS to have KDE or Gnome, etc. In fact if you look at the minimal installs for more distro's they don't even have X11. Something like this will probably be the base. It is effecient both performance wise and in terms of the work involved.

This will have a package manager. It is basically guaranteed if Pandora wants to be what it states it is. That being said, that will not hinder games/emus. They can run fine on this.

People can boot into the WM if they want to or not. Or you could have the WM run on one VT and have the games emus switch to a different VT. There are multiple ways of doing this. ALL REQUIRE SOME FORM OF LINUX DISTRO.

I think this has discussion has gone from package management, to how Pandora it self will function in terms of the OS. Linux will not hinder gaming/emulators.