Skip to content
Snippets Groups Projects

Default to extra repo for new packages when no repo is specified

Closed Antonio Rojas requested to merge arojas/devtools:default-to-extra into master
1 unresolved thread

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.

Edited by Antonio Rojas

Merge request reports

Pipeline #98549 passed

Pipeline passed for a802e27c on arojas:default-to-extra

Test coverage 35.62% (0.00%) from 1 job

Closed by Antonio RojasAntonio Rojas 8 months ago (Jun 9, 2024 2:16pm UTC)

Merge details

  • The changes were not merged into .

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Antonio Rojas changed the description

    changed the description

    • 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 in kde-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 Polyak
    • Author Contributor

      The 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.

    • Please register or sign in to reply
  • 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.

Please register or sign in to reply
Loading