I think it would only be useful when the PNDs do not need any kind of modification. This should be possible, either by placing those compatibility libs to the global library search path (might not be such a good idea), or by setting a PND specific library search path through libpnd when running a PND.Custom Processing Unlimite said:
I didn't know someone else has been trying to run Arch on the Pandora before. Thanks for the link.Custom Processing Unlimite said:
).
I would like to avoid this for a few reasons:Tempel said:
Sorry, I misunderstood what you were doing here. I had envisioned two packages; let's call them libpnd and pandora-compat. The first, libpnd, would contain just libpnd. The second, pandora-compat, wouldn't actually contain anything, and would simply depend on all the libraries that appear in the official Pandora firmware (including libpnd); end users could install this package to quickly get all libraries that apps expect to see on a Pandora. I thought you had combined both of these into one package, pandora-libraries, but instead I see that you're using pandora-libraries just to hold libpnd. I would recommend actually calling it libpnd (that's what it is, after all), but the name hardly matters. However, I would still recommend making pandora-compat; again, it doesn't have to hold anything, it just has to depend on things.wejp said:
Yes, but that shouldn't stop us from including what's already there. Consider a user trying to run a PND in Arch; they can search for and install packages to try to make it run, but eventually they find that one package doesn't exist. If they had installed pandora-compat, they would already know it doesn't exist. That PND won't run either way, but having the pandora-compat package saved a lot of time trying to find that out. Also, PKGBUILDS for old versions can be made gradually, even if they're not all available now.wejp said:
Two things here: First, I really don't understand the problem with "polluting" the system with old libraries. The two libraries sit next to each other with different filenames and different package names. If a program asks for the new library, it'll get it; if it asks for the old library, it'll get it; if it doesn't specify which version it wants, it'll get the new one. Of all the old library packages I've seen, this is how they always work; there are no conflicts, because programs always get what they want. What makes it a bad thing?wejp said:
I named it "pandora-libraries" because that's what it is officially called, not libpnd (which is part of the pandora-libraries).Tempel said:
I understand what you mean and it makes somewhat more sense now, but I still don't really see the point of doing that. One can expect that all native Arch applications use the more recent libraries, so the older ones really are only useful for compatibility with PNDs. When that's the case, I would simply package those libraries as I said. If you are willing to build and create packages for every single missing one (there are a lot of libraries and for most of them there are no packages available), go ahead. I don't think it is worth the effort, though.
Having all the required libs would save them even more time and it would actually run. In most cases I would build one package for each library, but in this case, I don't see any advantage of this. Either you want to install that compatibility stuff or you don't. It is highly unlikely that you want to install only a few of those libraries.
I know all that, but that's not what I meant. The only use of those packages is to run applications that have not been built for that system, but for another one (the Pandora OS). All those libraries are not needed for normal system operation, but only for running those PNDs.
That's not the point. I don't care much about what programs/games packaged as PNDs link against. They will always link against the libraries available in the defualt OS and that's fine. But when those old packages are available in Arch by default, people might start linking against those libs.
Updating pandora-compat in your scenario is always way more time consuming than with simply reusing the official libs in one compatibility package. Again, what is the advantage of doing that?If you convince them to do that, then it's a simple matter to update pandora-compat to depend on the newer library instead of the older one.
To conclude, I really think this is the easiest way: it allows us to take advantage of existing packages rather than trying to get all of these libraries into one package. I really wish I had a Pandora now so I could make it happen, but until then I'll just have to argue
That's ok, I simply do not see the advantage in your approach. PNDs will always use different versions of libraries to some extent. There is nothing to be done about that as long as Arch is not the official OS, which is why I would simply take those libraries as they are and bundle them in a single compatibility package instead of putting effort into rebuilding and packaging all those libraries. All that time could be put into something more useful.
:blink: I even have that repository cloned on my machine, yet never noticed the name. It only contains libpnd-related stuff (for now), but yeah, you win this onewejp said:
Yep, that's what I meant. Sorry, if I wasn't clear enough.Tempel said:
I was a little confused about the name at first, too. I guess as that repository contains a few menu related things too, they did not name it libpnd as libpnd is only a part of it, even if it is the most important part.:blink: I even have that repository cloned on my machine, yet never noticed the name. It only contains libpnd-related stuff (for now), but yeah, you win this onewejp said:
tar xJvf filename.tar.xzsudo mount -o remount,dev /media/mmcblk0p1Actually, you do not need to specify the compression mehtod at all with almost all tar versions currently in use. So all you need to do is "tar xfv archive", where archive can be uncompressed tar, .tar.gz, .tar.bz2 or .tar.xz .Tempel said:
Mounting with the dev option should not be necessary, but should not do any harm either.
I'll keep that option in mind or the next version. This might save some bytes, but even then the archive should still be extracted with the root user. If anyone has trouble extracting the archive as it is now, you are doing something wrong - either you aren't extracting as root or the filesystem on the target device is incompatible, e.g. fat instead of ext2. As said in my blog, the filesystem should be ext2 and nothing else (yes, this includes ext3 as well - do not use it).Letalis Sonus said:
