vinipsmaker
Member
PNDManager won't manage .deb dependencies. It can delegate the task to apt-get. It only do this to make the light PNDs reliable. Don't like it? Use flat pnds.
The software side
- Thread starter aTc
- Start date
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
I have no interest in flame wars (Just saying I sometimes download PNDs on my desktop and copy to the SD cards, there's no malice in my tone).I also don't even know what the "most recent solution" is! It's hard to find any real information in this thread, because it's buried by crap.
vinipsmaker
Member
Most recent solution is a system that support both, flat PNDs and light PNDs. light PNDs would have a list of .deb dependencies. It'll please everyone.
Useful information:
http://pandorawiki.org/New_PND_format#The_2014.2FPyra_effort
Last edited by a moderator:
My main mode of operation is downloading pnds to the SD card on my desktop machine. I do realize that things might be different on the Pyra than now, but I'd just like to point out that pmprog is not alone in this.
vinipsmaker
Member
We have enough time and you started to work on a tool that will give us a lot of power.
EDIT/P.S.:
I liked your current signature.
Last edited by a moderator:
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
The problem with design by committee! Although, I'm not sure what's exactly fragile about the PND system?
I think one of the main reasons people download PNDs on desktops is that the Pandora's WiFi isn't always particularly reliable. If the Pyra's is, then it might not be as much of an issue.
At the same time - the idea of putting PND's on SD cards inheritantly screams that you need to be able to copy them without T'internet - because if two Pyra's meet up, one might say "yeah, give us a copy of that app", and bang - copied via SD.
Isn't that the point?
vinipsmaker
Member
The point is to serve the user and some of us want to reduce the duplication of dependencies.
You can do the same thing that I'll do: Download the flat pnds.
@pmprog, the current fragility is that there is not really defined guidelines for packaging PND.
So they are not really self-contained, they just work with current firmware because it's in kind of "frozen" state.
.next for example which aims to be complicant with PNDs already has breakage, so you mostly need to introduce compatibility layer.
iOS (dunno about android) isn't really self contained either.. They just have single framework you dynamically link against (which is imo also bad, since you can't backport features to older iOS versions and it brings more version handling boilerplate to developer). Everything else that is not in the iOS is of course linked statically or the dynlib is included.
Introducing two kinds of "PNDs" is just going to make things more complicated IMO.
I would leave packages that have dependencies stay as .deb and PNDs totally self-contained.
So they are not really self-contained, they just work with current firmware because it's in kind of "frozen" state.
.next for example which aims to be complicant with PNDs already has breakage, so you mostly need to introduce compatibility layer.
iOS (dunno about android) isn't really self contained either.. They just have single framework you dynamically link against (which is imo also bad, since you can't backport features to older iOS versions and it brings more version handling boilerplate to developer). Everything else that is not in the iOS is of course linked statically or the dynlib is included.
Introducing two kinds of "PNDs" is just going to make things more complicated IMO.
I would leave packages that have dependencies stay as .deb and PNDs totally self-contained.
Last edited by a moderator:
vinipsmaker
Member
> new device supports GPS
> new Android introduces suppport for GPS
> I made an app that uses GPS
> app requires newer Android version, Android is bad and not self-contained
At least they have a reason.
Did you even read the full post?
Because the situation about downloading when NOT using the Pyra was a few lines below?
Expect when accesing the GPS api from older android (the library is just layer to the internals).It could return error status for unsupported OS version or something, instead of making developer check for all kinds of OS versions for different code paths.
Most of the library changes in iOS for example are UI elements, which makes no sense to update whole OS for..
vinipsmaker
Member
API that didn't exist in older versions? This reminds me of the DOS apps. I was reading on the wikipedia and I've read some messy things about how they could use more RAM.
Yeah... we developers are humiliated by decisions of the marketing team... and we have to take it, because the f****** users.
Things on the OpenPandora community here are different.
Read my post fully. The api doesn't exist and it would notify developer so when he accesses it using the framework.Of course, we don't have such convient frameworks so the situation is much more complex for us.
Last edited by a moderator:
vinipsmaker
Member
Yeah, they have enough resources and they could be nicer.
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
Apparently not. I apologise.Did you even read the full post?
Because the situation about downloading when NOT using the Pyra was a few lines below?
SeeThruHead
Member
- Joined
- Dec 23, 2010
- Messages
- 112
I'm going to preface this post by saying that I am not a computer programmer, nor a linux user or even a pandora owner. So please feel free to laugh at or ignore this post as you see fit. That being said I am a user of android devices like the nvidia shield and android smartphones and I'm curious why a system that seems to work on these devices could not be borrowed/improved upon for the use of the Pyra.
You could turn PND into self contained offline installers the way I believe apk's are. They could be copied from any pc to sd card and then run from the pandora. The application would be isntalled into the main nand and then the pnd could be deleted. You could then give the user the option (lets say in an application manager) to move the app to an sd card and create a symbolic link from the original location to the moved content. Of course it's more complex than that like moving only data files or code that is specific to that app but you guys would know better than I. Then you have a background process that when the sd card status changes it checks the health of the symbolic links and enables/disables (or shows/hides) apps as necessary. The end result it seems would be a system that seems (to the end user) to work like the current pnd system in most use cases. Is this feasible or is my ignorance about linux preventing me from seeing the flaws?
You could turn PND into self contained offline installers the way I believe apk's are. They could be copied from any pc to sd card and then run from the pandora. The application would be isntalled into the main nand and then the pnd could be deleted. You could then give the user the option (lets say in an application manager) to move the app to an sd card and create a symbolic link from the original location to the moved content. Of course it's more complex than that like moving only data files or code that is specific to that app but you guys would know better than I. Then you have a background process that when the sd card status changes it checks the health of the symbolic links and enables/disables (or shows/hides) apps as necessary. The end result it seems would be a system that seems (to the end user) to work like the current pnd system in most use cases. Is this feasible or is my ignorance about linux preventing me from seeing the flaws?
Last edited by a moderator:
But what does "totally self-contained" even mean? If you use bash, perl, python, java and ruby, do you have to include all of them and their dependencies? Do you want to statically link against all libraries, even libc? Maybe you need to include a copy of the kernel too, just to be sure...
"Totally self-contained" is not an option. There have to be at least some dependencies. On the Pandora, there were plenty of deps, but they were implicit, which means the firmware cannot really be upgraded without breaking some deps and thus some PNDs. That is not a future-proof solution in the long term, and it is the main cause of headaches for firmware maintainers.
My proposal is to make it explicit what the deps are, so the deps can be handled in a sensible way. It's an extra feature -- you don't have to use it if you don't like it. But if you don't declare deps, you don't get to complain if suddenly your PND no longer works on a virgin firmware since you were depending on something without including it or declaring it.
Of course libc and such are backwards compatible by design. There has to be drawn line to somewhere of course.
We discussed on IRC though, and I'm fine with runtime with set of dependencies allowed to be dynamically linked, as long as that runtime is well defined. This way it's not too much hassle to include in different distro either.
I guess this is same as we discussed on IRC?
https://github.com/Pyra-Handheld/TODO/issues/7]https://github.com/Pyra-Handheld/TODO/issues/7
Last edited by a moderator:
I don't like having to define a runtime now, knowing that we will be stuck with it forever. E.g. today it would have to include relatively old versions of GTK and Qt and SDL etc, because they are still used. At some point we may want to get rid of those, but it will be impossible because it will break stuff.
If you are using SDL 1.2 and you can just specify that as a dependency, then even if in 5 years everyone has only SDL 2.4 and SDL 3.0 installed on their device (which could be the successor of the Pyra by then), things will still work because the explicit dependency will tell your device to download the legacy version of the library.
I'm trying to envision a PND format that will still work nicely in a decade or even two. Not something that works fine now, is still OK when the Pyra is released, becomes "meh" a year later and a minor pain in the donkey one year after that.
If you are using SDL 1.2 and you can just specify that as a dependency, then even if in 5 years everyone has only SDL 2.4 and SDL 3.0 installed on their device (which could be the successor of the Pyra by then), things will still work because the explicit dependency will tell your device to download the legacy version of the library.
I'm trying to envision a PND format that will still work nicely in a decade or even two. Not something that works fine now, is still OK when the Pyra is released, becomes "meh" a year later and a minor pain in the donkey one year after that.
