The Pnd Package Manager

Is this something that you would use?

  • Yes, definitely.

    Votes: 84 77.8%
  • Well, I don't know; I'd really need to have the feature that I'm going to specify below.

    Votes: 7 6.5%
  • Nah, the File Archive is enough for my needs.

    Votes: 10 9.3%
  • Yeah, and I'd help improving it.

    Votes: 7 6.5%

  • Total voters
    108

Bosbeetle said:
Correct me if I am wrong but does this mean that the uploader of the PND package also hosts the file? This means when the uploader turns his/her computer/pandora whichever it is uploaded from off the file is 'gone'

In that case Id rather see a central server like the file archive.

(turning a computer off might be blasphemous to some persons but a lot of us do turn it off once in a while)

and excuse all my noobness
No, because the PND Manager will not run on your computer/Pandora/w.e. It will run on a web server somewhere, and that web server will have a database that stores the data for you. The PND Package Manager "hosts" the file for you on a server somewhere, so it will not get lost. You will simply access the PND Manager through your web browser. Think of it in the same way that you think of the Pandora File Archive; they are very similar in functionality.
 
Last edited by a moderator:
dflemstr said:
Bosbeetle said:
Correct me if I am wrong but does this mean that the uploader of the PND package also hosts the file? This means when the uploader turns his/her computer/pandora whichever it is uploaded from off the file is 'gone'

In that case Id rather see a central server like the file archive.

(turning a computer off might be blasphemous to some persons but a lot of us do turn it off once in a while)

and excuse all my noobness
No, because the PND Manager will not run on your computer/Pandora/w.e. It will run on a web server somewhere, and that web server will have a database that stores the data for you. The PND Package Manager "hosts" the file for you on a server somewhere, so it will not get lost. You will simply access the PND Manager through your web browser. Think of it in the same way that you think of the Pandora File Archive; they are very similar in functionality.

Ah okay but this sever somewhere, is that defined? Which server is it, yours?
 
Last edited by a moderator:
Ok, your last explanation made a lot of sense. The only problem that I still see with it would be the splintering effect between files in your site and the File Archive. I tend to think that relying on all of the devs to choose your system over the official File Archive is going to result in a split like I described, and end users will need to look in both places for everything. Sorry, I can't give a good reason as to why I believe that this will happen (mostly that people use different criteria for deciding which option is better, or none at all and just pick something), however I really do think that this will be a problem.

It is possible that after your system gets up and running, and people start using it, the next step might be to talk to Ed about possibly combining efforts, or asking him to give you an API, or some easy way to find new files and pull them over. That way you don't need to worry about it too much while you're trying to get your system up and running, but after the bugs get worked out, the users will have a single place that they can go for things.

All in all, I'd say that this looks like an interesting idea, and I'll be interested to see where it goes.
 
emil10001 said:
Ok, your last explanation made a lot of sense. The only problem that I still see with it would be the splintering effect between files in your site and the File Archive. I tend to think that relying on all of the devs to choose your system over the official File Archive is going to result in a split like I described, and end users will need to look in both places for everything. Sorry, I can't give a good reason as to why I believe that this will happen (mostly that people use different criteria for deciding which option is better, or none at all and just pick something), however I really do think that this will be a problem.

It is possible that after your system gets up and running, and people start using it, the next step might be to talk to Ed about possibly combining efforts, or asking him to give you an API, or some easy way to find new files and pull them over. That way you don't need to worry about it too much while you're trying to get your system up and running, but after the bugs get worked out, the users will have a single place that they can go for things.

All in all, I'd say that this looks like an interesting idea, and I'll be interested to see where it goes.
I still don't have a host for this; I had hoped that I would be able to contact ED and ask him for a host, but this will only be possible after I have made sure that the application is rock solidly stable.

It is not possible to integrate this with the file archive, because the file archive is running on a closed-source platform, uses a completely different database/storage system, so this will not be possible. Get used to the thought :p
 
Last edited by a moderator:
Sounds nice, but i wouldnt really use the html UI for much, but if we get a proper application that runs on the pandora (X11 GUI) and caches the package names and descriptions for offline browsing, i'll a bit indirectly use your system happily. Use case:
1. I'm offline doing something on the pandora, thinking "i an need app to do X"
2. I open the local package manager app
3. I search (still offline) the descriptions for the app i need
4. I find something i need, i put on the data modem link to get it, and only a single HTTP request goes out to get the pnd file.
5. I've downloaded and installed it, i go offline again and use the app i just got.
 
Having read your explanation, I am willing to give my opinion on such a service.

What you describe as a "PND Package Manager" sounds to me as a "PND Package Repository with fetching/upload frontend". A manager manages whatever is installed on your local system, and makes sure it gets the files from any source it requires, offers removal, etc. Meaning it has to run ON the local system and actually manage (install/remove/reinstall/configure) software.

If such a repository (as you describe) doesn't synchronize/cooperate with other services properly, it is completely worthless. This includes the File Archive, other instances aside from the "official" PND Package Manager (hey, people will want to run their own mirroring services, especially when they notice the archive is down the few seconds you decide to reboot it), and it would be a disservice if you didn't also cooperate with Angstrom's builtin package management, IPKG. You'd risk community fracture and would make the world a lot more confusing if you leave this synchronization out.

What you intend to do is adding layers upon layers of complexity, even though all you need is a simple list of packages (with some meta-information, such as screenshots, etc.) and the packages themselves. Those services are already being provided by the IPKG system that is builtin Angstrom. I say we elect an official Pandora IPKG mirror that includes regular exports of the PND files from the File Archive. If all you intend to do is "Have the user select a PND package from a fancy interface, grab that file, drop it on the Pandora", you'd be better off writing an application akin to Debian's goplay (showing meta-info of all packages of a certain category), and make it talk to Pandora's native package manager. Uploading the way you described will be a simple matter of updating the File Archive to make it extract screenshots and other meta-information from the PND file itself. Simplifying the upload process of PND files should NOT be a reason to develop a completely new package repository which would not integrate with other (still accepted and used) systems. Also, you'd have to have some kind of authentication and versioning capabilities, which would mean people who still use the File Archive would have to associate their OpenID to their old account on the File Archive, and unless the File Archive implements OpenID, the relation between authors there and here would be lost.

There's always the matter of localized cache, conflicting packages, background retrieval, mirroring and synchronization of different repositories. None of that is a problem if there was a way to integrate all content of the File Archive with the IPKG system.
 
polyroy said:
Having read your explanation, I am willing to give my opinion on such a service.

What you describe as a "PND Package Manager" sounds to me as a "PND Package Repository with fetching/upload frontend". A manager manages whatever is installed on your local system, and makes sure it gets the files from any source it requires, offers removal, etc. Meaning it has to run ON the local system and actually manage (install/remove/reinstall/configure) software.
There is no literal definition of what a "Package Manager" is. It manages PND packages, so therefore that's the name I gave it. If you have a better one, please tell me (it could be called a repository but that would not describe its whole nature).
polyroy said:
If such a repository (as you describe) doesn't synchronize/cooperate with other services properly, it is completely worthless. This includes the File Archive, other instances aside from the "official" PND Package Manager (hey, people will want to run their own mirroring services, especially when they notice the archive is down the few seconds you decide to reboot it), and it would be a disservice if you didn't also cooperate with Angstrom's builtin package management, IPKG. You'd risk community fracture and would make the world a lot more confusing if you leave this synchronization out.
IPKG will not be officially supported on the Pandora, or at least that's what skeezix has told me. It is possible to have multiple managers on multiple places that mirror each other, I just said that the PND Manager cannot use a completely foreign database layout as its primary database system, something that would be necessary to "sync with the file archive". The file archive was never built for package management, and it's impossible to sync with it. I never said that it would be impossible to sync other kinds of repos, however.

polyroy said:
What you intend to do is adding layers upon layers of complexity, even though all you need is a simple list of packages (with some meta-information, such as screenshots, etc.) and the packages themselves. Those services are already being provided by the IPKG system that is builtin Angstrom. I say we elect an official Pandora IPKG mirror that includes regular exports of the PND files from the File Archive. If all you intend to do is "Have the user select a PND package from a fancy interface, grab that file, drop it on the Pandora", you'd be better off writing an application akin to Debian's goplay (showing meta-info of all packages of a certain category), and make it talk to Pandora's native package manager. Uploading the way you described will be a simple matter of updating the File Archive to make it extract screenshots and other meta-information from the PND file itself. Simplifying the upload process of PND files should NOT be a reason to develop a completely new package repository which would not integrate with other (still accepted and used) systems. Also, you'd have to have some kind of authentication and versioning capabilities, which would mean people who still use the File Archive would have to associate their OpenID to their old account on the File Archive, and unless the File Archive implements OpenID, the relation between authors there and here would be lost.
There's always the matter of localized cache, conflicting packages, background retrieval, mirroring and synchronization of different repositories. None of that is a problem if there was a way to integrate all content of the File Archive with the IPKG system.
The File Archive is a file uploading site. Nothing more. It has never even been used as a package management system before; everything that has been done with it until now could as easily have been done with MediaFire. And again, IPKG will not be supported. There's nothing that I need to integrate with.
 
Last edited by a moderator:
dflemstr said:
It is not possible to integrate this with the file archive, because the file archive is running on a closed-source platform, uses a completely different database/storage system, so this will not be possible. Get used to the thought :p

The File Archive's backend might be somewhat closed, but the front-end is still HTML. You can structurally get all the information you need just by spidering. I wouldn't call the system closed just because you don't have access to the data the way it's internally stored, you don't need that much!
 
Last edited by a moderator:
polyroy said:
dflemstr said:
It is not possible to integrate this with the file archive, because the file archive is running on a closed-source platform, uses a completely different database/storage system, so this will not be possible. Get used to the thought :p

The File Archive's backend might be somewhat closed, but the front-end is still HTML. You can structurally get all the information you need just by spidering. I wouldn't call the system closed just because you don't have access to the data the way it's internally stored, you don't need that much!
Yes, you are indeed correct; it would be possible to spider the site (As I have already mentioned) and the database structure could be analyzed and used to do some kind of synchronizing. However, since the File Archive to date does not contain any PND packages at all, then what would be the sense in enabling users to upload their PNDs to an obsolete site when the file is going to end up in the manager anyways? Again, there is no reason why people would want to have access to PNDs in the File Archive, judging by the responses I've been getting so far. So why bother?
 
Last edited by a moderator:
Sorry for the double post; I would just like to say that I've managed to get my old server I've had standing in the closet up and running again, and it's now serving the PND Manager (albeit with very little content). You can find it here: http://pndmanager.dyndns.org/pndmanager/
 
dflemstr said:
There is no literal definition of that a "Package Manager" is.

Yes there is: http://www.google.com/search?rls=en&q=define:package+manager

dflemstr said:
IPKG will not be officially supported on the Pandora, or at least that's what skeezix has told me.

I can't believe they would decide against a pre-installed package manager. If it's running Angstrom, IPKG is supported. They might not run their own Angstrom mirror, but that does not stop us from running one containing all PND files wrapped with simple installer scripts.

dflemstr said:
It is possible to have multiple managers on multiple places that mirror each other, I just said that the PND Manager cannot use a completely foreign database layout as its primary database system, something that would be necessary to "sync with the file archive". The file archive was never built for package management, and it's impossible to sync with it. I never said that it would be impossible to sync other kinds of repos, however.

I guess what bothers me is that the system you describe deviates from the traditional way of offering a package repository. Mirroring is as simple and universal as wget -r when you use an FTP or HTTP backend without any frontend other than standard dirlisting. Upload is another thing, but that is trivial however, especially since it is "auth, dump, and run" since the PND file contains all information.

dflemstr said:
The File Archive is a file uploading site. Nothing more. It has never even been used as a package management system before; everything that has been done with it until now could as easily have been done with MediaFire. And again, IPKG will not be supported. There's nothing that I need to integrate with.

The beauty of a repository is that it is simple; MediaFire/File Archive/FTP, what's the difference? Oh, you mean the Package Manager installed locally on your system which knows how to interface those sources you say? Then why would we need a complex server with a novel interface which does not function with standard tools?

I don't agree with IPKG not being supported, it runs Angstrom for crying out loud. There is already a need for package management; all non-PND-wrapped software! You say you want "apt-get like" interfaces, but that's IPKG for you. Please consider that.
 
Last edited by a moderator:
dflemstr said:
Yes, you are indeed correct; it would be possible to spider the site (As I have already mentioned) and the database structure could be analyzed and used to do some kind of synchronizing. However, since the File Archive to date does not contain any PND packages at all, then what would be the sense in enabling users to upload their PNDs to an obsolete site when the file is going to end up in the manager anyways? Again, there is no reason why people would want to have access to PNDs in the File Archive, judging by the responses I've been getting so far. So why bother?

I'd say the File Archive is the central repository for this kind of handhelds. It would make sense to continue the tradition of software offerings there. Of course, it would boost Pandora sales when people discover that the Pandora has certain titles they seek.

But, aside from that, I acknowledge that using the File Archive is cumbersome and that something really simple such as an FTP archive for PND files would suffice to replace it. We might actually end up doing the reverse; updating the File Archive for completeness whenever things change in the main repository.

I have a request for you. Could you read through the way IPKG and DPKG are implemented (if in the least to improve your understanding) and use a system that uses such package management with multiple sources for a while? I'm not sure if you have done any of that, but you might realize the beauty and simplicity associated with it then. Really, a repository is a single source, I currently have about 20 different repositories from which I update my laptop, and can install any piece of software instantly. Everything is very easily interfaced, the only thing that's missing is a minimalist graphical interface to that frontend specific for the Pandora.
 
Last edited by a moderator:
polyroy said:
dflemstr said:
There is no literal definition of that a "Package Manager" is.

Yes there is: http://www.google.com/search?rls=en&q=define:package+manager

dflemstr said:
IPKG will not be officially supported on the Pandora, or at least that's what skeezix has told me.

I can't believe they would decide against a pre-installed package manager. If it's running Angstrom, IPKG is supported. They might not run their own Angstrom mirror, but that does not stop us from running one containing all PND files wrapped with simple installer scripts.

dflemstr said:
It is possible to have multiple managers on multiple places that mirror each other, I just said that the PND Manager cannot use a completely foreign database layout as its primary database system, something that would be necessary to "sync with the file archive". The file archive was never built for package management, and it's impossible to sync with it. I never said that it would be impossible to sync other kinds of repos, however.

I guess what bothers me is that the system you describe deviates from the traditional way of offering a package repository. Mirroring is as simple and universal as wget -r when you use an FTP or HTTP backend without any frontend other than standard dirlisting. Upload is another thing, but that is trivial however, especially since it is "auth, dump, and run" since the PND file contains all information.

dflemstr said:
The File Archive is a file uploading site. Nothing more. It has never even been used as a package management system before; everything that has been done with it until now could as easily have been done with MediaFire. And again, IPKG will not be supported. There's nothing that I need to integrate with.

The beauty of a repository is that it is simple; MediaFire/File Archive/FTP, what's the difference? Oh, you mean the Package Manager installed locally on your system which knows how to interface those sources you say? Then why would we need a complex server with a novel interface which does not function with standard tools?

I don't agree with IPKG not being supported, it runs Angstrom for crying out loud. There is already a need for package management; all non-PND-wrapped software! You say you want "apt-get like" interfaces, but that's IPKG for you. Please consider that.
I am not responsible for package management on the Pandora; I am not an official developer. I just threw the idea out there a month ago that we'd need a central way to manage PND files - the only package format supported by the Pandora - and some people, including some devs I recall, agreed that I should at least try. This is nothing official, and therefore I ask for your opinions and not "You are doomed to get this, what do you feel about that, eh?". I am very happy that you can come with constructive input; of course the PND manager could be rebuilt to use a file system for actual PND file storage; when I built the database system, I made sure that this was possible. You would lose a lot of performance, however, unless you want to stream packages directly from disk, which exposes you to file integrity issues.

And about IPKG: it won't be possible to use, since it requires you to have persistent storage on the Pandora. Since Pandora lacks internal, always-present storage (beyond the 512 megs on the fragile NAND), it won't be possible to use a management system that expects files to stay where they are and always exist until removed. We need a system that can handle the constant swapping of SD cards.

Also, they (aka the Pandora devs) wanted to remove the "installation" step of packages, and have something that never needed to be installed. As you might or might not know, PND packages aren't even extracted before being used, they are used as-is. This wouldn't be possible with IPKG packages that have various install scripts attached to them.

I do think that core updates to the core Ångström OS (such as firmware, bootloader and kernel updates) will happen through IPKG, but that all other packages should be installed through PNDs. And remember: it's probably possible to write scripts that automatically convert IPKGs into PNDs, so this won't be an issue (just simulate a Pandora env, run the install scripts and preserve the output tree, wrap it in a PND and done).
 
Last edited by a moderator:
polyroy said:
dflemstr said:
Yes, you are indeed correct; it would be possible to spider the site (As I have already mentioned) and the database structure could be analyzed and used to do some kind of synchronizing. However, since the File Archive to date does not contain any PND packages at all, then what would be the sense in enabling users to upload their PNDs to an obsolete site when the file is going to end up in the manager anyways? Again, there is no reason why people would want to have access to PNDs in the File Archive, judging by the responses I've been getting so far. So why bother?

I'd say the File Archive is the central repository for this kind of handhelds. It would make sense to continue the tradition of software offerings there. Of course, it would boost Pandora sales when people discover that the Pandora has certain titles they seek.

But, aside from that, I acknowledge that using the File Archive is cumbersome and that something really simple such as an FTP archive for PND files would suffice to replace it. We might actually end up doing the reverse; updating the File Archive for completeness whenever things change in the main repository.
I don't believe in tradition. I don't even celebrate Christmas ;)
And simple FTP will not suffice. We cannot, for example, let people upload unvalidated PND files to somewhere (I have encountered various possible exploits in the current format, and unless those are fixed, we can't let PND files spread without control).
But it would of course be possible (As mentioned above) to move the storage of PND files out of the PND manager and to a file system. People would upload files in the PND manager and then have FTP read-only access to them. As I said,it's only been me working on this project so far; I'd really appreciate if someone could assist me in improving it in whichever way is required.

EDIT:
I have a request for you. Could you read through the way IPKG and DPKG are implemented (if in the least to improve your understanding) and use a system that uses such package management with multiple sources for a while? I'm not sure if you have done any of that, but you might realize the beauty and simplicity associated with it then. Really, a repository is a single source, I currently have about 20 different repositories from which I update my laptop, and can install any piece of software instantly. Everything is very easily interfaced, the only thing that's missing is a minimalist graphical interface to that frontend specific for the Pandora.
Hey, what makes you think that I haven't already done this? I understand how systems like this work (albeit not the itty gritty details) and thought about them when designing the current repository format. Believe me, it's not that bad.

Here are some principles that I've adhered to with the current system (tell me if there's something that you think is missing on the list):
  1. Packages are immutable. In the PND Manager, you can never edit a package, and a package can only exist once in the system. It is possible to delete a package, but this is required to enable moderation.
  2. Packages are uniquely identified. I have had a very lengthy discussion about this a while ago here (skip the first part; it's a proposal that was scrapped). A package is identified by name + version, and there can't be two packages with the same name and version. Versions are also enumerable, so there won't be issues with in which order upgrade paths should be ordered.
  3. Package repositories can be used synchronously. If you have two or more PND Managers on multiple hosts, and merge their repository file lists, you will only get conflicts if there are two packages with exactly the same name and version in both repositories, an issue that also exists in dpkg/ipkg. Otherwise, there are no issues whatsoever with having multiple repositories.
  4. PND files have strict naming rules. These aren't enforced upon the users, but when downloaded, PND files will always have the name "<name>-w.x.y.z.pnd" to avoid name collisions.
  5. PND repository entries are always identified by name/version, never by database ID (screenshot links and details links are; but with the REST system this shouldn't matter since you can always rely on the URLs being in a specific location, and thus the contents of the URLs are insignificant)
 
Last edited by a moderator:
Oh, wasnt .pnd just uncompressed .iso with a footer XML, so totally uncompressed (?).
The repository should allow access to the pnds in some highly compressed form (like LZMA or bz2),
that would be decompressed on-the-fly (as it comes in) by the on pandora software.
We will be using slow links anyways.
 
I don't really think we need or want to have packages spread across multiple servers, it's confusing and a pain. What would be potentially quite useful would be to get a site like this for the platform. www.freshports.org basically to help us know when to look for updates and quickly find things that might be of interest.

Spreading files, no matter how well intended, is unlikely to be worthwhile for really anybody.
 
Well I like it. I like the spirit with which this has been tackled - you indentified problems, found some solutions and went ahead with actually doing something about it, and made sure it was open and extensible.

The main objections on this thread seem to be:

  • We need a central location for storage - I wouldn't like to see that fractured
  • I prefer x package manager

I think that if there could be some agreement that this(or more precisely an evolution of this) should be the prefered central storage for pandora applications then everyone could move on with discussing improvements and integrations that would make it work for everyone.

Maybe this could be extended so that a single frontend could be used for the File Archive and the PND packages. Maybe the pnd files could be mirrored in a file system for FTP access. Maybe there could be integration with this forum to allow for comments/voting on packages. Once something solid is agreed, it's more likely that people could work on a single package management system on the Pandora that would be able to access this and the Angstom repositories.

I've voted definitely yes in this Poll, I'd vote more categorically that this shows potential and should be seriously considered by Openpandora as something official if such a poll were to exist.

a
 
dflemstr said:
File Archive: You specify a file to upload, give it a description, give it a screenshot, metadata, version information, etc, etc, and THEN you upload it.
PND Manager: You upload the PND file, the PND Manager automatically opens and organizes the file, and you are done. All screenshots etc are loaded automatically.
These two features require completely different backends, and since the File Archive doesn't support post-processing of uploaded files, I can't really do anything with it.
And what about "PND Uploader"? Application that upload PND file to File Archive and fill those description, screenshots etc for user. So not new File Archive backend, but new frontend (client application). This application can even check File Archive for new version of PND.

edit: bb code correction
 
Last edited by a moderator:
dflemstr said:
I am not responsible for package management on the Pandora; I am not an official developer. I just threw the idea out there a month ago that we'd need a central way to manage PND files - the only package format supported by the Pandora - and some people, including some devs I recall, agreed that I should at least try. This is nothing official, and therefore I ask for your opinions and not "You are doomed to get this, what do you feel about that, eh?". I am very happy that you can come with constructive input; of course the PND manager could be rebuilt to use a file system for actual PND file storage; when I built the database system, I made sure that this was possible. You would lose a lot of performance, however, unless you want to stream packages directly from disk, which exposes you to file integrity issues.

And about IPKG: it won't be possible to use, since it requires you to have persistent storage on the Pandora. Since Pandora lacks internal, always-present storage (beyond the 512 megs on the fragile NAND), it won't be possible to use a management system that expects files to stay where they are and always exist until removed. We need a system that can handle the constant swapping of SD cards.

Also, they (aka the Pandora devs) wanted to remove the "installation" step of packages, and have something that never needed to be installed. As you might or might not know, PND packages aren't even extracted before being used, they are used as-is. This wouldn't be possible with IPKG packages that have various install scripts attached to them.

I do think that core updates to the core Ångström OS (such as firmware, bootloader and kernel updates) will happen through IPKG, but that all other packages should be installed through PNDs. And remember: it's probably possible to write scripts that automatically convert IPKGs into PNDs, so this won't be an issue (just simulate a Pandora env, run the install scripts and preserve the output tree, wrap it in a PND and done).

I did not realize PND files would be operated this way. Your choices seem to make a lot more sense now. There are two kinds of packages; those "portable" PND packages, and those internal continuously available to the OS. You should not confuse the two, as they cannot really be used interchangeably. I sure hope there is a way to make some PND packages integrate with the OS, in the way that they create the appropriate binaries and shared files in the proper locations so that e.g. a music player provided through a PND is always available through the classical UNIX mechanisms (mpd, music playing daemon, for example).

Your last statement makes me irk; if you were to wrap part of /usr/bin and part of /etc/ in PND's, you'd have to search all PND's on the system for providing those files. So I don't think this is viable. It only works with simple apps which are not integrated in the system at all. For all other purposes, I believe there is no alternative to either IPKG or a complete reinstall. Or you'd have to make PND's which spew content all over your NAND when run, in the traditional "big fat update" kind of way. For simplicity, the latter might be the choice, but for developers, IPKG is really something you cannot go without. You need inter-dependencies and dependency handling as much as possible when you only have 512MB to work with. AFAIK you can't have half the /usr/bin entries from one source and the other half from another, unless you do some kind of fancy symlinking, which is something quite tedious when it comes to installation (deciding which files go where). You're really talking about thousands of IPKG packages with interdependancies which PND cannot even have knowledge about.

dflemstr said:
I don't believe in tradition. I don't even celebrate Christmas ;)
And simple FTP will not suffice. We cannot, for example, let people upload unvalidated PND files to somewhere (I have encountered various possible exploits in the current format, and unless those are fixed, we can't let PND files spread without control).
But it would of course be possible (As mentioned above) to move the storage of PND files out of the PND manager and to a file system. People would upload files in the PND manager and then have FTP read-only access to them. As I said,it's only been me working on this project so far; I'd really appreciate if someone could assist me in improving it in whichever way is required.

I've learnt to reuse existing systems as much as possible. If you innovate too much and people have a hard time interfacing, you lose it all. Simply documenting interfaces isn't enough, you need to ensure proper availability of the data in as much ways as possible. The proper way to do that is use classical widely accepted readily available tools. I hope this explains my reasoning.

About direct package acceptance, well, that's the grand issue isn't it. PND files will have to be signed by the developer that uploads it (thereby making it immutable). You can't know if the executable is malicious or not, they might've added a backdoor somewhere anyway. So it makes sense to allow any uploads immediately (you can do only basic validation without guarantees), and use a feedback system for validation (number of downloads, trust of author, removal after reports).

dflemstr said:
Hey, what makes you think that I haven't already done this? I understand how systems like this work (albeit not the itty gritty details) and thought about them when designing the current repository format. Believe me, it's not that bad.

Here are some principles that I've adhered to with the current system (tell me if there's something that you think is missing on the list):
  1. Packages are immutable. In the PND Manager, you can never edit a package, and a package can only exist once in the system. It is possible to delete a package, but this is required to enable moderation.
  2. Packages are uniquely identified. I have had a very lengthy discussion about this a while ago here (skip the first part; it's a proposal that was scrapped). A package is identified by name + version, and there can't be two packages with the same name and version. Versions are also enumerable, so there won't be issues with in which order upgrade paths should be ordered.
  3. Package repositories can be used synchronously. If you have two or more PND Managers on multiple hosts, and merge their repository file lists, you will only get conflicts if there are two packages with exactly the same name and version in both repositories, an issue that also exists in dpkg/ipkg. Otherwise, there are no issues whatsoever with having multiple repositories.
  4. PND files have strict naming rules. These aren't enforced upon the users, but when downloaded, PND files will always have the name "<name>-w.x.y.z.pnd" to avoid name collisions.
  5. PND repository entries are always identified by name/version, never by database ID (screenshot links and details links are; but with the REST system this shouldn't matter since you can always rely on the URLs being in a specific location, and thus the contents of the URLs are insignificant)

Ah, I'm sorry. I am more of a minimalist KISS kind of person, dealing with the tools we already have. Your plan was to make it "Web 2.0" (please forgive me for using that term), and my plan was to make it use conventional systems. Because of that I assumed you didn't know about the KISS-approach.

I acknowledge that, in order to do more with a file repository than is offered here, we need some metadata techniques. Since there are so much candidates for metadata, the REST API you have implemented might be the better of the candidates.

And I agree with Urjaman's use case scenario. That'd be a priority requirement if it were for me. Flag for retrieval, install whenever I say it's possible, but it does require the local client to be developed. I'd prefer a local client interfacing the API itself directly to any web interface using AJAX anyway, and I'm probably not alone :)

hedwards said:
I don't really think we need or want to have packages spread across multiple servers, it's confusing and a pain. What would be potentially quite useful would be to get a site like this for the platform. www.freshports.org basically to help us know when to look for updates and quickly find things that might be of interest.

Spreading files, no matter how well intended, is unlikely to be worthwhile for really anybody.

Well, having no master repository would be a bad thing. I was thinking of mirroring only for faster access on different hosts, and the ability to appoint another master whenever one went down (even temporarily). If it were to grow big (with lots and lots of game data), a distributed system (at least for the backend) would be needed, and it is good to be ready for that.

dflemstr, thank you for your attention and the implementation so far, I wish you lot's of success in perfecting it.
 
Last edited by a moderator:
I would hate to have to use the File Archive to get software.

The way I see this PND "Package Manager" is a very cool way (on the Pandora or not) to get software for the Pandora.

I can easily see the points to some of the arguments but some of them are "linux user" arguments and seem to be semantic battles, etc. If the file archive can't sync with anything (this or any other project like it) easily, then it seems to me that it needs to be replaced. Someone came up with something user friendly and I think we should embrace it. If we need also to come up with a new File Archive, I think that's what needs to be done. If projects like this get shot down because they're not linux enough, then the Pandora will be just as nichey as linux itself. I would rather have an easily browsable online database like this than a crappy Package Manager in the classic sense any day.
 
Back
Top