The software side


Being able to download PND's from my Windows PC, copy to SD card, insert into my Pandora, have it show up in the menu, and play
According to http://boards.openpandora.org/topic/15574-confliting-requirements/#entry311187 and _wb_, this feature won't be available to Pyra. Maybe.


EDIT:


Just to make clear: you'll need to connect the Pyra to the internet to be able to do software installation.
It doesn't have to be like that. Nothing stops you from putting .deb files on an SD card and installing them from there. Also, once you have a reasonably up to date and complete base system, there is no need to be connected to the internet when installing a new .pyra, because its dependencies will be ok.

My proposal just wants to avoid the main problem with .pnd, which is that if you as a dev want to use something that is not in the default base system, you essentially become a package maintainer for your dependencies too, and some dependencies will even get multiple "maintainers" that way. E.g. the author of PNDManager effectively has to maintain libqt too. That is not a good way to do things.

Of course nothing stops devs from specifying no dependencies at all and including everything in the .pyra file. I just don't want that to be the only way to reliably do stuff.
 
Last edited by a moderator:
Nothing stops you from putting .deb files on an SD card and installing them from there.
Wrong. Dependencies.
It shouldn't be too hard to automatically get all dependencies too.

To be honest, I don't see the point of downloading something on a PC from the Pyra or Debian repo, then putting it on an SD card and installing it on the Pyra that way. It sounds like an annoying detour to me. Or are there that many people still with only wired internet and/or no internet but a heap of CD-ROMs ?
 
My proposal just wants to avoid the main problem with .pnd, which is that if you as a dev want to use something that is not in the default base system, you essentially become a package maintainer for your dependencies too, and some dependencies will even get multiple "maintainers" that way. E.g. the author of PNDManager effectively has to maintain libqt too. That is not a good way to do things.
The makepnd system that Cloudef is developing will make everything better.

But there is one thing that would be good. We should create a pandora-deps metapackage that forces a minimum set of dependencies that the developer can always rely on. This minimum set of dependencies MUST include sdl and sdl2 (and that *-image, *-gfx, ...). This would make the system more future-proof, avoiding outdated sdl libs on packages that don't work with newest graphical and sound systems.
 
To be honest, I don't see the point of downloading something on a PC from the Pyra or Debian repo, then putting it on an SD card and installing it on the Pyra that way. It sounds like an annoying detour to me. Or are there that many people still with only wired internet and/or no internet but a heap of CD-ROMs ?
Well, just provide a .deb package and upload it to the repo, because if your package will need internet access to be installed, it doesn't make much sense to put it in the SD card as a self-containing package anyway.

And your package manager will only upload the installed .deb packages, not the .pyra packages.
 
To be honest, I don't see the point of downloading something on a PC from the Pyra or Debian repo, then putting it on an SD card and installing it on the Pyra that way. It sounds like an annoying detour to me. Or are there that many people still with only wired internet and/or no internet but a heap of CD-ROMs ?
Well, just provide a .deb package and upload it to the repo, because if your package will need internet access to be installed, it doesn't make much sense to put it in the SD card as a self-containing package anyway.
Why not? Once your base system is updated, the .pyra package is still self-contained, unless you have other Pyras lying around with outdated/incomplete base systems -- it will not work on those if you don't have an internet connection or other method to bring them up to date. In a sense, this is exactly like it is now on the Pandora.

Do you think currently .pnd files are really self-contained? They're not. They also depend on packages in the base system, only those dependencies are not made explicit. This is the reason why an old PND can stop working in a more recent version of SZ, or why a new PND may require a certain version of SZ to work properly.
 
Nothing stops you from putting .deb files on an SD card and installing them from there.
Wrong. Dependencies.
 It shouldn't be too hard to automatically get all dependencies too.

To be honest, I don't see the point of downloading something on a PC from the Pyra or Debian repo, then putting it on an SD card and installing it on the Pyra that way. It sounds like an annoying detour to me. Or are there that many people still with only wired internet and/or no internet but a heap of CD-ROMs ?
Depending on the package, it is impossible to do manually. To get the right dependencies you would need a list of installed packages and versions on the Pyra and internet access at the same time. Would be possible to make helper tools, but would still be annoying.
Personally I don't need a way to use the Pyra without internet access. I was just pointing out possible flaws in people's reasonings and tried suggesting better solutions.

Edit: Oh and yes, .pyras definitely need .deb-dependencies.
 
Last edited by a moderator:
Why not? Once your base system is updated, the .pyra package is still self-contained, unless you have other Pyras lying around with outdated/incomplete base systems -- it will not work on those if you don't have an internet connection or other method to bring them up to date. In a sense, this is exactly like it is now on the Pandora.
>Once your base system is updated

>the .pyra package is still self-contained

I think these two expressions don't play well together. And I stand my point: if you want dependencies, just use .deb files.

I don't like the idea of two systems that integrate well. If we follow this idea, Steam will be better than us, Android will be better than us, iPhone will... everyone. I will offer nothing to develop an inferior system (that works on Pyra #1 and fails to run on Pyra #2), because I want the challenge to develop something good.

And again, the Cloudef's makepnd tool will likely make developer's life easier.

Do you think currently .pnd files are really self-contained? They're not. They also depend on packages in the base system, only those dependencies are not made explicit. This is the reason why an old PND can stop working in a more recent version of SZ, or why a new PND may require a certain version of SZ to work properly.
I know they depend on libraries installed on the OpenEmbedded derivate. But nobody uses the opkg to uninstall packages and the system barely updates. It IS safe to rely on these dependencies. You don't need internet access to use a new downloaded PND file.
 
Nothing stops you from putting .deb files on an SD card and installing them from there.
Wrong. Dependencies.
sure : http://apt-offline.alioth.debian.org/

Used this about 10 years ago, was working like a breath. Should still be the same ;)
Okay, make sure to include this and instructions how to use it. Maybe add an optional front end for beginners. And then let's start to assume everyone is able to keep their system up to date.
 
It doesn't have to be like that. Nothing stops you from putting .deb files on an SD card and installing them from there.
sure : http://apt-offline.alioth.debian.org/ Used this about 10 years ago, was working like a breath. Should still be the same
Seriously? This system is too fragile.

PND-game Foobar needs libabc. It include libabc on the SD-card. libabc requires updated version of libdef. An old version of libdef was already included in the system, because maybe Firefox or any app was already installed. But your system included an updated libdef, because your system is brilliant. Now I update libdef and Firefox stops working? Why? Because libdef doesn't maintain ABI compatibility and packages need to be recompiled. Congratulations, you fucked my system.

And yes, this issue is real. I saw proprietary or manually compiled packages stop working several times complaining about libpng or something else.
 
Seriously? This system is too fragile.
So you can tel us a story were it failed on you ? Never happened to me. I used it weekly for about a year...
And yes, this issue is real. I saw proprietary or manually compiled packages stop working several times complaining about libpng or something else.
Any closed/proprietary software not using static linking to distribute under linux ? just loll
 
So you can tel us a story were it failed on you ? Never happened to me. I used it weekly for about a year...
PND-game Foobar needs libabc. It include libabc on the SD-card. libabc requires updated version of libdef. An old version of libdef was already included in the system, because maybe Firefox or any app was already installed. But your system included an updated libdef, because your system is brilliant. Now I update libdef and Firefox stops working? Why? Because libdef doesn't maintain ABI compatibility and packages need to be recompiled. Congratulations, you fucked my system.

Any closed/proprietary software not using static linking to distribute under linux ? just loll
Whatever, you're defending a fragile system. Can you suggest a solution to situation above? It's a good thing you didn't design the current Android system.
 
PND-game Foobar needs libabc. It include libabc on the SD-card. libabc requires updated version of libdef. An old version of libdef was already included in the system, because maybe Firefox or any app was already installed. But your system included an updated libdef, because your system is brilliant. Now I update libdef and Firefox stops working? Why? Because libdef doesn't maintain ABI compatibility and packages need to be recompiled. Congratulations, you fucked my system.
Here you go :

1*) On the offline PC:

sudo apt-offline set libabc-offline.sig --install-packages libabc

2*) On the online PC: (there is a windows binary available too)

sudo apt-offline get libabc-offline.sig --no-checksum --bundle libabc-offline.zip

3*) On the offline PC:

sudo apt-offline install /media/USB/abuse-offline.zip

Also work with update/upgrade and such...

With all your arrogance, what system do you offer that work up to *your* standard ? If this doesnt fit
 
If a library breaks compatibility, it should change its major version number. If my application depends on SDL 1.2, and another one depends on SDL 2.0, then there is no problem. The upgrade to SDL 2.0 will not remove SDL 1.2. An update to SDL 2.0.1 will not break anything, and whatever improvement the update makes, it will be there for everything that uses SDL 2, immediately. What is the problem?

An automated makepnd system could solve some of the maintainance issues, but it still doesn't solve the problem that you would have to do lots of updates to keep your PNDs up to date. If you have a 1GB game that happens to use libpng, you have to download it all over again each time libpng gets a tiny update.

You can argue that games don't really have dependencies and that PNDs only need to be used for games, but I'm not so sure about that. FIrst of all, I think games can have dependencies, and serious ones too, especially FOSS ones. E.g. games that use Python or Lua or whatever -- do you really want to put all of that inside the PNDs or fix in advance what is available and what is not? Also I think the PND system can also be nice for non-gaming big software, e.g. geographical stuff (GPS maps etc), scientific software with big data sets, and so on.
 
Back
Top