Default to extra repo for new packages when no repo is specified
Since the 1.1 release the --repo flag is only allowed for new packages, while the -t and -s flags are only allowed for existing packages.
This breaks release scripting in case one needs to release a set of packages which includes both new and existing packages (notably the kde-build scripts).
Default to extra for new packages to fix this issue.
If extra is not the intended target of a new package and one forgets to pass the --repo flag, the package can be easily moved afterwards.
Merge request reports
Activity
Releasing unknown packages blindly to extra sounds like a wrong fix for the mentioned problem, hence I'm not a fan of this. The target could as well be
multilib
or maybe even, as you mentioned, a new packages for KDE. we are not going to add a default fallback to our tooling which wrongly releases a potentially unusable package into stable repositories that should only exist inkde-unstable
while its being worked on. The premise of the release is to either be unambiguously automatic and correct or explicitly chosen.This leads me to the conclusion that the kde scripts need to be smarter about reasoning if a package is new, or not. Or find another way that doesn't lead to wrong results by default. A combination with the approach from !264 is a much better behavior without falling back to an error-prone default forcefully and would ensure a new package is only released into, where it could be successfully built.
Edited by Levente PolyakThe target could as well be
multilib
or maybe even, as you mentioned, a new packages for KDE.Hence the message that makes you aware that you are pushing to the wrong repo in that case, which can be quickly and easily fixed. Pushing a new package intended for multilib to extra by mistake is not going to break the distro.
we are not going to add a default fallback to our tooling which wrongly releases a potentially unusable package into stable repositories that should only exist in
kde-unstable
while its being worked on.This changes nothing with respect to unstable packages. They can be mistakingly pushed to the stable repos now exactly as they could before. This is meant to fix batch-releasing of packages to the stable (or testing) repos.
This leads me to the conclusion that the kde scripts need to be smarter about reasoning if a package is new, or not.
Fine, whatever. I just don't see how the "should be using more of the official tooling instead of custom scripts" combines well with official tooling getting more constrained with each release instead of catering to the actual packagers' use cases.
Instead of going hyperbole maybe it would be healthier working together in shared middle ground. If you re read the answer you will notice that your concern has been taken into account and hence the an MR mentioned by me which addresses this issue, as well as the loophole to release an unstable by accident to the stable repos. Please don't go mad if downsides of an approach has been clarified, when an alternative better solution has been provided in the very same explanation.