Package Manager Repos

[Squidge]

I'm still thinking along the lines of: Developers are 'lazy'. They do what they are interested in. So when it becomes time to start throwing betas out, they are not going to start calculating dependancies and making fancy .deb files. They are going to zip up there build directory and post it somewhere. People will download this archive and throw it onto a sd card expecting it to work straight off. Sure, some will create .deb's for certain versions (some maybe every version), but you can't expect everyone to do it. We need to make a standard so that people don't have to install emu X in one way and emu Y in a completely different way.

Secondly, there will be people not wanting to waste battery life downloading apps and libs. They want to download the apps using there PC into a directory (eg. coding compos/etc) and then extract directly to an sd card, before finally throwing that card into the Pandora expecting it to work.

Then we have the thousands of people with a GP2X who are used the above methods, and those who don't want to download apps, put them on the SD card, and then install from the SD card to the SD card and then delete the original installation files. Thats a complete waste of time & erase cycles. More complex apps will need to be like this, but lets not make it complicated for apps that will have not dependancies apart from the default libs.

Sure, there can be package management for the more complex apps (KDE apps, etc), but we shouldn't expect everyone to abide by it. Homebrew and emus will likely never use anything more than the default installed libraries (which includes SDL) anyway, so a package manager isn't required here.

 

[BaDToaD]

It would be interesting to know what proportion of the voters that want a package manager are currently GP32/GP2x owners. I'd expect the % to be very low.
Most of us that have been here for years have come to realise that Squidge's posts are usually grounded in logic and common sense.
I'll just return to lurking in this topic for now I'm interested to see how it pans out

 

[ldesnogu]

I'm still thinking along the lines of: Developers are 'lazy'. They do what they are interested in.
(...)

Secondly, there will be people not wanting to waste battery life downloading apps and libs. They want to download the apps using there PC into a directory (eg. coding compos/etc) and then extract directly to an sd card, before finally throwing that card into the Pandora expecting it to work.

I globally agree with you and I am agnostic as far as static linking or package management is concerned. Things should be as easy as possible for both the dev's and the users.

However I see a big flaw in what you say:

1. dev's are lazy, granted
2. users want to save power

This is completely not compatible. I am 100% sure you will waste more battery playing with your newly app than downloading it and its dependencies. Add to that that since programmers are lazy, you can be sure some of them will require you to overclock your unit, resulting in even more power consumption using the app.

Basically I think your argument is flawed... for power saving that is

 

[prak]

Sure, I can agree that droping just working rootfs is sane option, as long we can get fairly good documentation what went there, so we could provide metadata for whatever package system. Also, would be nice too know patches were required to make it working, and what BLOBs were put there (hope not many). I would hate situation, that you've got with Nokia tablets, where you just can't adjust something to your needs, like kernel, or just becouse X or Y will stop working. I am aware, that we can't avoid some BLOBs like EGL, Wifi??. Would be nice to know how can we get those too.

I do only afraid, that after some time, you'll have to do one of:
1) link static
2) -rpath
3) distribute everything you use, set LD_LIBRARY_PATH in script, and run your binary

None of this is very bad/wrong, nonetheless, I am sure that sooner or later some folks will get something more elaborated (atleast I do have some plans for this). Don't see problem if that is not default, as long there is way to go with something more. Unified way of handling packaging would be nice, but I agree, that it does require quite bit human resources, to make everyone happy.

Everyone that tried run LFS for longer time, most likely understands why packaging was invented.
Keeping it clean is doable, it is fun, but not always you wish to have this kind of fun. Yes, I've seen FOSS version of DLL Hell*.

As for programmers doing packaging... yes, they are lazy, but usually, for autotools projects it is not big effort, check configure.ac, or when you have binary, use ldd to see what it links atleast. Depends only on community size. As for unpackaged stuff on my systems, I usually CODE
make install DESTDIR=/tmp/something
and use importare from paludis (alternative gentoo package manager) to install, provide metadata. Sometimes I write ebuild, mainly when it is needed by someone else. I have some idea, how I will be handling that...


(*) M$ Corp. All rights reserved.

 

[sindbad]

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?

Packages for app media, skins and whatever else can be made.
And the talk of evil comes from me.

I'm still thinking along the lines of: Developers are 'lazy'. They do what they are interested in. So when it becomes time to start throwing betas out, they are not going to start calculating dependancies and making fancy .deb files. They are going to zip up there build directory and post it somewhere. People will download this archive and throw it onto a sd card expecting it to work straight off. Sure, some will create .deb's for certain versions (some maybe every version), but you can't expect everyone to do it. We need to make a standard so that people don't have to install emu X in one way and emu Y in a completely different way.

Secondly, there will be people not wanting to waste battery life downloading apps and libs. They want to download the apps using there PC into a directory (eg. coding compos/etc) and then extract directly to an sd card, before finally throwing that card into the Pandora expecting it to work.

Developers are lazy and that's a good thing, but they don't have to make debs if they don't want to. And if they do, there are easy to use tools for that. Or the repo maintainers can make the debs for them.

Not everything has to use the package manager. Games can either use the 'drop folder/cramfs/squashfs to sd card and expect it to work' or the 'point package manager to zip file with all depencencies'.
But the base system (kernel, sdl, X, default gui) and many other things(PIM, IM, browser,...) will desperately need one.

 

[Squidge]

Basically I think your argument is flawed... for power saving that is

Less power wasted installing app = More power to play with app

Developers are lazy and that's a good thing, but they don't have to make debs if they don't want to. And if they do, there are easy to use tools for that. Or the repo maintainers can make the debs for them.

Not everything has to use the package manager. Games can either use the 'drop folder/cramfs/squashfs to sd card and expect it to work' or the 'point package manager to zip file with all depencencies'.
But the base system (kernel, sdl, X, default gui) and many other things(PIM, IM, browser,...) will desperately need one.

Agree

(Finally )

Now, who wants to be the repo maintainer?

 

[sindbad]

Agree

(Finally )

Phew

Now, who wants to be the repo maintainer?

You should have know that no one would volunteer. Especially not the ones who praised the idea.

 

[Arialia]

Agree

(Finally )

Now, who wants to be the repo maintainer?

:lol: i think it is the more difficult to find a volunteer

so i agree with you Squidge

homebrewers are lazy sometimes and all don't know how make *.deb

also i think libraries like SDL, SFML must be dynamic, so all games made with it could benefit of future optimization of libraries B)

 

[Javacat]

Feel free to shout at me if you don't like this idea, but how about something along these lines:
Squidge has already stated that the most common libraries will be included in the 'standard' distro. How about as devs are working on their programs they can send requests to the distro devs to add support to any 'common' libraries that they would like adding to the distro, so that they don't have to dynamically link into them. The more requests they receive to add a library and whether it's already been ported or not should increase the chances of it making it into the next distro release.
For people that do have access to wifi connections they could then run some package managing thingy to update their system with the latest/newest libraries available for the system and people that don't have wifi will have to upgrade to the latest distro. The people using the package manager thing would then be able to also easily test the latest versions of library releases before they make it to the next 'stable' distro release.


Edit: Forgot to say that you could then follow the GP2X method of distributing apps and installing them by just dropping straight onto the SD.

 

[Orkie]

I personally think installing a full desktop distro on the NAND is a bad idea anyway - it would be much better to format your SD as ext2/3 and chroot, with a script that launches the GUI as the shell argument for chroot. Or just boot off SD of course.

 

[AireTamStorm]

Basically I think your argument is flawed... for power saving that is

Less power wasted installing app = More power to play with app

Developers are lazy and that's a good thing, but they don't have to make debs if they don't want to. And if they do, there are easy to use tools for that. Or the repo maintainers can make the debs for them.

Not everything has to use the package manager. Games can either use the 'drop folder/cramfs/squashfs to sd card and expect it to work' or the 'point package manager to zip file with all depencencies'.
But the base system (kernel, sdl, X, default gui) and many other things(PIM, IM, browser,...) will desperately need one.

Agree

(Finally )

Now, who wants to be the repo maintainer?


We'll want several people to maintain the repos, and I guess I'll be the first to volunteer. Have we decided upon APT with a GUI?
I'll read up on and start experimenting setting up APT repositories.

Devs, just PLEASE include apt as a bare minimum on the default OS..
And may I pray for htop as well? :lol:

 

[Megamixman]

I'm still thinking along the lines of: Developers are 'lazy'. They do what they are interested in. So when it becomes time to start throwing betas out, they are not going to start calculating dependancies and making fancy .deb files. They are going to zip up there build directory and post it somewhere. People will download this archive and throw it onto a sd card expecting it to work straight off. Sure, some will create .deb's for certain versions (some maybe every version), but you can't expect everyone to do it. We need to make a standard so that people don't have to install emu X in one way and emu Y in a completely different way.

Generally in the build environment, libraries are not kept in the build directory. Most compilers by default dynamically link. So they would still be packaging the build directory. Package scripts for the most part can detect which libraries are needed and build the packages for them. There really is very minimal extra work.

Less power wasted installing app = More power to play with app

An immeasureable amount.

For things like games where no depedencies are needed other then the base system the package would be nothing more then an archive with a file saying "extract to this dir". Still they could just not make a package and that is fine. The case we are talking about is when additional dependencies are involved. It is that case where package management is needed and is likely to happen for everything pandora will be doing with the exception of games, but even they can be dependency based.

I don't have a problem managing a repo. I really like the Pandora concept, so I do want to contribute what little time I can.

 

[zodttd]

I think APT would be a great option, and I know someone who could do it too! The iPhone uses two package managers, Installer.app which is doing its own thing specific to Apple products, and Cydia.

Cydia uses APT and is gaining momentum. It's by Saurik of www.saurik.com and I really love his work.

Maybe he would be up for a Pandora version of Cydia?

Pre-compiled packages are the way to go for such handhelds. APT works great, and we could get a lot of support from handhelds that already have APT built in.

 

[Squidge]

Some people might find this interesting:

http://video.google.com/videoplay?docid=64...71753&hl=en

 

[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:

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.


Thank you for the explanation!

I'd like a nice GUI, of course (and I expect that there will be several choices for a GUI eventually). I'm also not sure I want my system automatically deciding what to download for me. I'd like to have full control over what's on my SD cards.

Besides, I think automatic downloading would require an internet connection, and I don't have Wi-Fi in my home.

 

[Hooka]

I would say that having a nice linux/windows repository client for downloading to a directory, SD or through usb to the pandora for those without wireless accessibility would be optimal if the repository path was taken...

And personally, even though APT is a great system I'd much rather go with something more tailored to the Pandora... allowing it to specify whether to install to NAND or SD, telling how much available space is on either (on pandora client anyways), including a pandora-friendly sized icon, full documentation (similar to gmenu2x's nice little Doc stuff) & extensions for easily copying/moving rom's/datafiles into the proper directory, aggressive dependency checking (should be minimal if everyone is married to static linking ), license identifier, separate source packages (Not enforced, just available for opensource stuff if people want to, I'd presume more for the computer client, allowing a prospective developer to d/l and work with the source code to a game he likes on his pandora without having to either hunt down the author [who may become listed MIA] or losing it due to a website long gone... although, who knows maybe some crazies wanna dev on their pandora's... I'd probably try and pull it off between courses at college/uni)

One last little idea that might be nice in a system like this would be to set system "roles", so you could use it for your intended purpose... low level gaming, X system, Wireless router all-in-one secure box, linux terminal, artist/writer, etc. but I'm just a crazy, overzealous fool

To simplify it on the developer end of things, make a GUI driven program that allows them to setup the package like they want as easily as possible, providing defaults for people in a hurry (aka, have everything from author, license, release date, version, icon, source, binaries, data install dirs, etc.)

...but if there was such a package management suite for Pandora I'd wanna call it Box....

And dammit, if there are some other really crazy people who actually like my idea I'd probably work on a design for it, but I'd guarantee I'd need help to make it something production worthy...

Hell, while I'm busy jumping over the deep end, lets suggest that eventually we could even have it setup for commercial games with encrypted packages and online webstore type service...

 

[AireTamStorm]

I would say that having a nice linux/windows repository client for downloading to a directory, SD or through usb to the pandora for those without wireless accessibility would be optimal if the repository path was taken...

Here's the solution to everyone's problem. APT is very flexible, you should be able to force an install to a non-standard directory if you need to. All we'd need is a fancy front end. I've got a little bit of a desktop GUI idea. By downloading packages onto the SD card, and setting a file in the root directory with a flag that queues the pm on the pandora to do an install, we could end up with something nice.

So:
You search for games on your Desktop Package Downloader.
You find one, and set it to install to SD.
Desktop Package Downloader goes and grabs a game. It asks you where to install it, you point to your SD card.
The PD puts the package onto the SD card, and drops a text file in the root directory of the SD card.
The PD downloads all necessary dependencies and drops them into the SD card as well.

You pop the SD card into the Pandora, and fire up the package manager.
The PM sees the text file on the SD card, telling it to install all the downloaded packages to the SD card.
The PM takes care of the rest, installing the game and all its deps.

If we were to use Qt or GTK we'd have the advantage of the downloader app working on Linux, Windows, AND Mac.

 

[sindbad]

If we were to use Qt or GTK we'd have the advantage of the downloader app working on Linux, Windows, AND Mac.
If you want 'AND Mac', gtk drops out of the picture. Only options are toolkits that use native widgets like WxWidgets(win, gnome, mac) or Qt(win, gnome, kde, mac).

 

[AireTamStorm]

If we were to use Qt or GTK we'd have the advantage of the downloader app working on Linux, Windows, AND Mac.
If you want 'AND Mac', gtk drops out of the picture. Only options are toolkits that use native widgets like WxWidgets(win, gnome, mac) or Qt(win, gnome, kde, mac).

I was under the impression that GTK ran under X in Mac?

Qt it is then, it is a bit more fully featured than GTK anyway. As of Qt4 many of the barriers of developing multi-platform apps on Qt disappeared.

So here's the new question: would the kind of system hooka is suggesting be acceptable to the guys that voted "SD cards" or "this is all a bad idea" on the poll? Basically it still breaks down to:

-The Pandora having a repository
-Packages having to be built by someone for the repository
-Someone (or many people) maintaining that repository
-People coding an APT or other front end for both the Pandora and Win/Lin/Mac.

The advantages:

-You can install applications from either the Pandora or another computer just as easily as the other.
-This will greatly improve the experience of the user due to ease-of-use. No copy/paste, just check a checkbox and you're off.
-The Pandora will behave like a proper Linux computer, not a crippled one.

The disadvantages:

-Getting all of this done is a ton of work.
-Somebody has to make packages, be it the developer or a package building service.

 

[javaJake]

I was under the impression that GTK ran under X in Mac?

Indeed, if GTK doesn't run on a Mac, I'd like to know what OpenOffice 2.4 (stable version, not the alpha junk) is using for its interface.