Since nobody has stepped up to the task yet, I'm going to start implementing a package manager subsystem soon. ED has mentioned that milkshake intends to create a repo for dbps, so most of these questions are directed at him, although general input is welcome.
The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.
Next is documentation. Is that to be included the current PND-way (does it work well?) or should a separate system be used for it? A separate system means it'll probably be access by different means than through the program menu. Since the linux desktop is in a broken state and multi-level program menues are more or less unsupported, this might be a good thing, as a long long list of documentation could be annoying to look though. If a separate system is employed, it should probably use the same markup format as the description, to simplify codebases (and it makes sense to have it available via the repo too, I guess.) If it's just desktop launchers pointing to an html or whatever, then I guess format is whatever the dev feels like.
I am undecided about the package lists. Part of me thinks a plain format like .desktop with a different section for each package ID will be sufficient, is there an argument for a hierichal format here?
I also suggest an optional changelog to be included in the package metadata. This should be a simple plaintext format that is both human and machine readable (so it needs a defined syntax.) An argument for machine readability is to allow a package manager to present changes from the currently installed version as compared to the one that can be updated to.
If I get no input on this, I will just do whatever I feel like, because this needs to be started on rather soon if there's to be a chance of having it all in a usable state by the time prototypes starts shipping...