On Sat, 2016-08-27 at 14:25 +0200, Axel Braun wrote:
Not all upstreams provide a signature - for the ones that do, I agree, we should use them. But it's at the maintainers to verify that there ARE signatures and use them.
Can you point me to a how-to or some documentation?
https://en.opensuse.org/openSUSE:Package_source_verification is the best I could find within 30s of searching :)
For Factory it's a no-go: we have to guarantee that source will never change except by means of a submission from a devel project. With enabled services we risk that any given package might just 'updated to latest git master' (possibly involving user error, but still). You have to understand that any such thing would more than just invalidate the entire staging and pre-integration testing workflows we do.
For git, agree that may be an issue. For the packages I maintain there is a distinct version number, so it does not change 'by chance', only by purpose in the spec-file. I don't see that a service download would do harm
I'm almost ready to guarantee that you will have move fun with a local script that happens to update all your 100 packages' spec files, .changes files and downloads the tarballs, ready to inject them into the package, than modifying all those files in the webui. What would happen if the tarball on the server changes in between service runs? They should not - but I have seen cases where it happens.
Services can be a great aid - but I don't see them fit in maintaining a project like Tumbleweed.
They can reduce workload dramatically: each supported version of Tryton (currently 6) has around 100 packages, where around 20% of them receive a monthly bugfix, resulting in a new minor version. Only 1 version should go to factory in the future, but the additional effort for local package handling does not really make me happy.... :-(
See above. With 100 packages linked together, the webui will prove the most inefficient of ways to handle the load. Cheers, Dominique