I don't mean purposefully relying on them, but only ever testing with versions with those effects. This is one case where neither party knowingly does any wrong, but the end result is a dysfunctional piece of software.
I actually do agree with you. I'm just pointing out it's not as clear cut as I interpreted you made it out to be.
You still need to show a reason why this should not happen, in reference to keeping a container format where portability and independency from the basic system are essential parameters.
Here are some reasons:
While saving space is always nice, I am for giving it a low priority in that particular discussion: space only gets bigger and or cheaper, the download & "install" experience may be improved, but most of the libraries we are talking about here are in the kB range, assets are probably eating most of the bandwith
This is indeed usefull, but again I'm asking to focus on the expected cases: Games. If speed is of importance in that matter, the author / maintainer is inclined to update it anyway. So whats the gain in having a new version other then that its newer ?
I guess we can expect a basic set of libs just to be there, preferable only those that have to be specifically adapted anyway.
There seems to be a vital flaw in my understanding of the situation: Wouldn't including more libraries into the pnd itself be actually more beneficial in order to achieve that ?
Space does not necessarily only get bigger and cheaper. The Pyra will have mobile data (3G), which tends to have less speed and be more expensive than wifi.
Games are not the only expected cases. I expect the Pyra to be useful for much more than just games.
And how do you determine which libs are considered "basic" and have to be "specifically adapted"? These are not at all clear-cut notions.
No, not necessarily. You would put a version of the dependency in the PND that was compiled for Debian, and that may or may not work out of the box on a different distro.
We don't need to alter external components: we can use the debian package manager as is. The change would be in the PND install/run system, and it would not be particularly hard to implement. Just a few calls to dpkg, essentially.
Are there many libraries that are big enough to add to the size significantly in comparison to other parts of the package, Qt comes to my mind, but anything else ?
Of course the Pyra will be usefull for much more than games (and if things are working out as they look like, gameing will be thing I will do the least on the Pyra). But I have my doubts that there will be much besides games that will see a release as pnd.
How often do speed increases of significance are introduced by changing the code of the library only ?
Everything that needs adjustments to make better use of pyras specific hardware and are deemed to have a more broader use, the only thing that comes to my mind is SDL. Good starting point to evaluate that further would be the current repo.
You obviously have more knowledge and experience in that field, so I can't really argue against that. I can only ask (more out of curiousity) are there cases where libraries need adjustments while the binary that depends on them does not need them ?
Ah okay, I thought the changes would affect "standard" components of the system. Thanks for clearing that up
For example: GTK, ImageMagick, Java, Webkit, GHC.
It is true that it is mostly games that will not already be present in Debian and/or that are big enough (because of data files) to not install it on the internal storage.
Lots of applications spend most of their time in executing library calls. A typical game will spend most of its time in calls to SDL or some other graphics library, music and sound libraries, and maybe some physics engine or something like that. During loading they will typically spend time in decoding libraries like libpng.
Define "needs adjustments" and "have a more broader use". Nearly everything could be adjusted to make better use of Pyra's specific hardware and nearly nothing needs to be adjusted (since it would also work as is, just slower). Almost by definition, libraries "have a broader use", because that's exactly the point of a library: to be used in more than one application. Of course some of them are more popular than others, and some of them are closer to the root of the dependency tree than others, but these things change over time and there is no clear-cut notion of that.
Sure. In a lot of cases the library offers some kind of abstraction to the application that uses it, so the application does not have to worry about hardware-specific or distro-specific stuff. When compiling the library, you would have to let it detect (or specify manually) where everything is located, what the conventions are, maybe which backend to use if there are alternatives, which optional functionality to enable (perhaps needing additional dependencies), etc. A lot of that configuration may be distro-specific. The applications themselves typically don't have that much distro-specific configuration: they're mostly happy when they can find their dependencies.
Fair point , but many of them are needed to be preinstalled already (like GTK to use XFCE). And most of these examples apply to applications. But I specifically asked and you specifically answered...
Why is a deb package no option in that case? Its a far more tried and tested mechanism, that also provides complete integration into the system, without any additonal effort from the pryas system dev team side
In my personal book, thats more a bad design decision - problem (to bundle the binary with asset data), than a regular case we need to handle (and will counter your own stance of wanting to reduce size of pnds where possible).
Of course everything can be adjusted to fit some scheme to counter an argument. But that is not the point:The pyra will deliver with certain amount of software preinstalled, this already determins the basis (like GTK). Going on from that, there will be some libraries that would "make sense" to include, like "SDL", which would be a case of "needs adjustmets to make full use of its potential. Of course this is a "cherry pick" process, as there is no universal sorting algorithm and this process will happen anyway independant of what mechanisms are included in the new pnd format/system.
So its usually more of "set path" problem then anything else ?
Maybe GTK will be preinstalled, but what if someone decides he likes KDE more and removes GTK? I want such things to be possible, without causing the PNDs to just crash. I want them to say: "This PND requires GTK, do you want to install it?".
Yes, that is a perfectly fine option if you can assume that everyone who wants the application always wants to install it on the internal storage.
Good point. Still, it makes sense to store the binaries at the same physical place as the assets, because one is useless without the other. So sure, you could distribute the GPS application as a smallish .deb package to be installed on the internal storage plus a large data pack to be installed anywhere, and that would be a reasonable workaround. But it would be nicer to be able to put the data either in a PND together with the binary, or in the appdata folder of the PND.
Yes, we already established that doing the same thing that was done for the Pandora can be done again. I'm arguing that this "cherry picking" process is not ideal since it unnecessarily forces everyone to have the same "cherries" or at least to manually try to keep track of which "cherries" he can remove (and then when he downloads a new PND try to figure out why it isn't working).
Compiled-in paths are one aspect of the problem, but also compile-time options like which back-end libraries it uses and which functionality is included (sometimes some not-so-frequently-used features are disabled by default).If it was just a question of paths then you could probably make everything work with some environment variables and/or symlinks, but there are other potential problems.
hmm, that makes a whole lot of sense, especially in context with the automated build server clouddef is proposing.
While there is always the possibility that someone does the unexpected, how likely is it ?
Argh, no, if its data that is likely to change, never, ever put it in same place. Picture Viewers/Video Players/Emulators/etc. are all useless without some form of "data", still usually you don't stuff this into the binary path (or one of its subdirectories). This even makes sense for some games, especially if they allow custom asset (like levels) creation.I define the appdata directory as a mobile/portable extension of the users home dir, so I am also against putting big stuff there, as this makes syncing/backing up userdata a lot more complicated/resource intensive without any real reason I could think of.
Hmmm, on my desktop I always prefer keeping them together. ie,
Don't know if this is comparable as (depending on your age) you might be trained by MS that there is no difference between binaries and data. The concept of having a directory for user specific data was introduced rather late in the Windows world. Your problem could easily solved with an emulator that remembers either the last used dir or a "standard" path to look for games (which do most emus on the Pandora, afaik).
I don't know why, but this made me chuckle. Is Windows NT 3.1 late in the Windows world? Anyway...
Given the "portable" nature of the PND(-replacement); it makes sense that you can grab the directory that has the program and all it's related data from one place and drop it into another (SD card for example).
It is not about system mechanisms to prevent you from puttings things were you think they belong, you can do this freely in any Linux system (you have elevated rights on) too, its about how users are "trained" to where stuff belongs: Like parents telling their kid in which drawer socks, underwear, trousers belong. Sure the kid can put them where he wants them to, but he can't expect that after the next loundry his parents will have adapted to the arrangement he thinks is best, but how they think its best.Since the early days of DOS/Windows seperating user data and system data is a complete mess that MS iterates over again with every new version released, which gets really annoying in the latest versions (like 7/8 ) with a whole bunch of virtual directories (with additional localized versions) that try to consolidate the mess they created over the years.
So the ideal situation would be that you (letting legal questions aside for a moment) can download emulator x and all the games for that specific system are included, it would be ultra portable right ? What if emulator x provides overall the best ui/emu performance but has a flaw in its emulation routines that makes some games not enjoyable, while emulator y provides a lesser overall experience but lets you play these particular game without problems ? Should every game be packaged into that pnd too ? Or in your case, would you copy your library in both appdata dirs, just for convenience ?
Sure.
That depends. The closest I've got to this scenario is Street Fighter III - where I had to move the games from MAME to FBA; because it ran slooow in MAME. But in such case, I wouldn't leave SFIII in MAME, what's the point if it doesn't play it properly.
So you would rather clutter your games over several directories than have them conveniently placed in one directory ? What if a new emulator comes up promising that it can do better than both before him, time to start digging through the file system ? Or there is a new version you hesitate to install because of possible drawbacks (some user may reported) ? Or you want to move to a new (e.g. bigger) SD-Card, but don't want to drag all the old crap that accumulated there (like several appdata directories of pnds you don't use anymore), time to start digging again ?This list goes on and on and on. Why have all these drawbacks? Just because of an old habit ?
which can get tricky if there are file name conflicts (like using different version of an emulator).
This was orginially planned for the pnd system too, but scraped because of overhead it produced while scanning the whole directory tree. You would also need another mechanism to decide where to place the "link" to the binary in the UI, which is also problematic as not every UI that will be possible provides the same mechanism for the user to customize the placement - one idea that quickly came to my mind was to just place an entry in the "start" menu and then let the user make a copy of that on the desktop if he wants it to appear there too. But thats not easy to do with XFCE and you would have to face the problem that there will be dead links as the pnd deamon would not know anything about copies.Edit: should update the thread before posting, so somewhat ninjad
Not just habit, but preference. I can see we're not going to see eye-to-eye on this, and that's fine.
Yep, but I've yet to encounter it...
Yep, as mentioned above, I understand why it's not done.
