- The current spec is missing any info on how to handle signed packages/trust. I would consider that a very important issue, as the package API is specifically meant for "third party" apps. Bmichaelsen
- Yes, security and trust is very important for third-party applications. Currently, the only means of security is that the API is designed after the least-privilege principle: the installer can only write to the files of his own installed package, and the package daemon ensures that no existing files are overwritten. Any ideas how security can be further increased through e.g. signing? Denisw
- This project may be re-inventing the wheel. GNUpdate has an API which allows integration into the different package databases. It also provides features this API has yet to address, including the ability to update software. Maybe work should go into reviving the project instead of starting a new one. See "Things You Should Never Do" by Joel Spolsky. TeapotPhilosopher
- I didn't know about the GNUpdate project. It is indeed worthwhile to look into it and see how it solves the problems addressed by the Burgorf Package API, especially where it does better (or covers aspects not handled yet by Burgdorf). Denisw
- Maybe an XML format could be standardized with community collaboration in order to provide better interoperability with other software installation efforts such as Zero Install. TeapotPhilosopher
- The current format is only an initial suggestion, and yes, I think we should get it to a final state with a community-driven process. I don't know if interoparibility with other projects such as Zero Install is necessary - it's probably hard because the needs are different (Zero Install also handles deployment for instance, whereas the Burgdorf format is a pure package description as the deployment method should be up to the software installer). Denisw
Please add any comments regarding the Burgdorf Packaging API here.