dflemstr
It's a ball.
yeah, where will /home/user be stored? 
Last edited by a moderator:
The New Pxml Format
- Thread starter dflemstr
- Start date
Vorporeal
Yes, no, I, this is.
I agree, this would be a good approach. As a dependency for programs (PNDs) that need it, you might also have to install a certain "library" PND, which would contain the needed library. It would just load the library from that PND. This means that any program that needs that library would get it from the same place, and it would be pretty easy to update. This does make it so that programs needing different versions of the libraries would require you to install multiple "library" PNDs, but they'd still take up no more space than packaging the library in with the software (unless it's statically linked).'dflemstr' said:A list somewhere with all the libraries that are included (including Python modules/eggs and Java JARs) would be very VERY helpful
And if you REALLY want to, is it possible to make a PND with, for example, lwjgl in it (which I guess won't be included in the core), and access that PND from another PND? (so that not every PND is huge because they have to include lwjgl)
Last edited by a moderator:
dflemstr
It's a ball.
(I guess that we're on-topic again)
But how would this work with the PXML system? Should there be a <requires>-field? Can we do some magic with the unque id? It would be a PITA to program.
And to the versioning system: Couldn't the maintainer do it like this: If a new library comes out that breaks compatibility, the old library isn't removed from the PND but the new one is just added, so that you have one pnd for for example lwjgl that contains all the versions.
So, if you want to install an app that needs lwjgl, it will say that it needs lwjgl with the minimum version X, and if you have a newer version it won't be a problem.
But how would this work with the PXML system? Should there be a <requires>-field? Can we do some magic with the unque id? It would be a PITA to program.
And to the versioning system: Couldn't the maintainer do it like this: If a new library comes out that breaks compatibility, the old library isn't removed from the PND but the new one is just added, so that you have one pnd for for example lwjgl that contains all the versions.
So, if you want to install an app that needs lwjgl, it will say that it needs lwjgl with the minimum version X, and if you have a newer version it won't be a problem.
Butterman
Gief Pandara
Isnt that over-complicating it a little? Why not have .pnd files for libraries, that include the version number in their description. That way, you distrubute any .pnd libraries you need as well as your app, if theyre already there, the average joe user will just be replacing them, not taking up any more space.
dflemstr
It's a ball.
It's not overcomplicating a little, because most of the time, an application will not work with a NEWER version of a library. This is what produces something like 50% of all Windows apllication failures: Application A installs dll foo.dll, then Application B installs a newer version of foo.dll and then Application A breaks. So, we need to keep the versioning system intact.
So, let's say that a 'newer version' PND of a library would contain all the previous versions, too (a .so is like 3 kb so it won't be a big deal). Then, every app includes it's required library PNDs, and if you overwrite an old library PND with a new one, it doesn't matter because the new one contains the old .so-files too.
So, let's say that a 'newer version' PND of a library would contain all the previous versions, too (a .so is like 3 kb so it won't be a big deal). Then, every app includes it's required library PNDs, and if you overwrite an old library PND with a new one, it doesn't matter because the new one contains the old .so-files too.
There is a library system for world of warcraft mods that acts like linux libraries (I think). When you download a mod you have the choice to download only the mod itself or the mod with libraries included. If you decide to download the mod by itself you must have the libraries installed as well, to use it. Also, the site is smart enough to parse a file to find what libraries are needed for the mod to run and includes them in the zip file on user download (if the user selects that option), that way people don't have to include any of them when uploading and the site only stores the user created stuff.
Would that work well here?
Would that work well here?
Last edited by a moderator:
Butterman
Gief Pandara
My opinion, was that having each and every .png file with libraries in it was silly. Now that I think about it, it's not that silly and would guartantee compatibility.'dflemstr' said:
Last edited by a moderator:
Vorporeal
Yes, no, I, this is.
True, but by adding an extra line to a PXML file, we could prevent having each program with its own copy by having library PNDs with one or more concurrent versions of the library in it. It would help prevent "DLL (.so) hell", which, granted, wouldn't be terrible, but having library PNDs would probably make it easier to make sure that dependencies are met.
Last edited by a moderator:
dflemstr
It's a ball.
OR we could just have some setting on the pandora that specifies some folder on the SD card (and changes the LD_LIBRARY_PATH) where you have to put ALL of your .so files (in <name>.so.<compatibilityversion> like the standard, eg libopenraw.so.1, look in your /usr/lib folder to get what I mean), and then we do something like DasFoool said (a zip with all dependencies).
Tor
Active Member
- Joined
- Oct 3, 2008
- Messages
- 709
Maybe that's true on Windows, but it's not true on Linux. It's extremely uncommon that a new library breaks an old binary, in fact that's called an ABI break and is considered a bug (if the major number is unchanged). When there's an ABI break the library major number should be bumped, so that the old library can stay in place for old binaries. And this happens very rarely indeed. As an example, look at 'libcurl'. It's been around for ten years at least, and new versions have been pushed out regularly (the current version is 7.19.something). The library major number has still only got to 4, so far. Libc itself is only at major number 6, and that includes some dramatic changes since 1991.'dflemstr' said:
New binaries with old libraries, now, that's a different story..
Last edited by a moderator:
dflemstr
It's a ball.
The need is obviously there, since we in fact have ld versions
Last edited by a moderator:
I never saw a system that share per application libraries.
There are tons of libraries that come with the core system (yes a listing/sdk will be available someday, but it's not the priority). You really shouldn't need any other libraries, and if it's the case, a library is, for most of them, a few Kb. So just include it in your app directory, it will be loaded when your application is launched.
Like you said yourself, sharing non-standard libraries between applications could lead to some big incompatibility/problems. I don't think there is the need here to do something overcomplicated.
There are tons of libraries that come with the core system (yes a listing/sdk will be available someday, but it's not the priority). You really shouldn't need any other libraries, and if it's the case, a library is, for most of them, a few Kb. So just include it in your app directory, it will be loaded when your application is launched.
Like you said yourself, sharing non-standard libraries between applications could lead to some big incompatibility/problems. I don't think there is the need here to do something overcomplicated.
Last edited by a moderator:
dflemstr
It's a ball.
What I mean is this: Look at allt he other distros; we have the ld .so versioning system for a reason. Look in /usr/lib to know what I mean; big symlink system.
But yeah, maybe all this is very redundant; I just don't like the fact that I'll have no possibility to share data between PNDs. Let's say that I have a tileset that's 10mb big, that I use in multiple games?
But ok, let's do this the Mac way, then. It's not like I lack download bandiwdth or anything
But yeah, maybe all this is very redundant; I just don't like the fact that I'll have no possibility to share data between PNDs. Let's say that I have a tileset that's 10mb big, that I use in multiple games?
But ok, let's do this the Mac way, then. It's not like I lack download bandiwdth or anything
Last edited by a moderator:
skeezix
Internal Development
omg, didn't know this thread was still going
For things like python.. included, or devs could include it in their apps (sucks.) Another option which I've been floating around is a variant of pnd that is mounted at boot-time. Or perhaps a special dir for pnds that automount.
The idea being we could have device-wide pnds, that aren't system updates. But I woudl expect a dpkg to install key system updates.. but if someone (say) wants to put in a dictionairy for a few apps (say), but without making a system update to put it on NAND, than a cool way would be to have a /pandora/automount (say) dir on SDs, that is scanned at boot, and all those pnds mounted (as normal), and then all other apps could just refer to /pandora/appdata/unique-id/.... to get the files (say,m or variations thereof.)
We're still working through it, and of course, a lot of things can be worked out later..
Of course, people couild copy their dictionairy or whatever files into NAND, or config the app to look on the FAT/etc filesystem on SD, or any number of things.
We don't really have to supply an implementation for everything ever conceived, the OS will let peopel do it
jeff
For things like python.. included, or devs could include it in their apps (sucks.) Another option which I've been floating around is a variant of pnd that is mounted at boot-time. Or perhaps a special dir for pnds that automount.
The idea being we could have device-wide pnds, that aren't system updates. But I woudl expect a dpkg to install key system updates.. but if someone (say) wants to put in a dictionairy for a few apps (say), but without making a system update to put it on NAND, than a cool way would be to have a /pandora/automount (say) dir on SDs, that is scanned at boot, and all those pnds mounted (as normal), and then all other apps could just refer to /pandora/appdata/unique-id/.... to get the files (say,m or variations thereof.)
We're still working through it, and of course, a lot of things can be worked out later..
Of course, people couild copy their dictionairy or whatever files into NAND, or config the app to look on the FAT/etc filesystem on SD, or any number of things.
We don't really have to supply an implementation for everything ever conceived, the OS will let peopel do it
jeff
Last edited by a moderator:
dflemstr
It's a ball.
Hmm... An idea that I just had but many others surely already thought about:
There could be a special file (say, that has to be in the root of a SD card and has to have the name "pandoraoverlay" or something), that:
1. Is checked for at boot (and only boot)
2. Gets checked wether or not it has a valid ext3 system on it
3. if it doesn't, gets formatted accordingly
4. and finally gets overlain over the NAND with unionfs
Then users could store stuff on their "NAND" more easily and move stuff about without having to go through page-long tutorials on how to set up an unionfs-system before the system works.
And, if the SD doesn't have the file, nothing happens. And no resizing of the file would happen (automatically, at least) so it would only take as much space as the user wanted.
Opinions?
EDIT: skeezix was faster...
There could be a special file (say, that has to be in the root of a SD card and has to have the name "pandoraoverlay" or something), that:
1. Is checked for at boot (and only boot)
2. Gets checked wether or not it has a valid ext3 system on it
3. if it doesn't, gets formatted accordingly
4. and finally gets overlain over the NAND with unionfs
Then users could store stuff on their "NAND" more easily and move stuff about without having to go through page-long tutorials on how to set up an unionfs-system before the system works.
And, if the SD doesn't have the file, nothing happens. And no resizing of the file would happen (automatically, at least) so it would only take as much space as the user wanted.
Opinions?
EDIT: skeezix was faster...
skeezix
Internal Development
See above
jeff
jeff
Last edited by a moderator:
Vimacs
Don't be evil!
also worth mentioning is probably that LD_LIBRARY_DIR is (currently)set to the path of the place where the .pnd is mounted on execution.
Vorporeal
Yes, no, I, this is.
Recent posts in Aimless_E's emulator frontend thread got me thinking:
Would it be of any use to include the MD5 sum of the ISO in the PXML file? It might be useful, and any PND creator (which I'm sure people will be using instead of creating PXML files by hand) would be able to easily automate the checksum process.
Would it be of any use to include the MD5 sum of the ISO in the PXML file? It might be useful, and any PND creator (which I'm sure people will be using instead of creating PXML files by hand) would be able to easily automate the checksum process.
Last edited by a moderator:
