Hi Ludo, On Sat, 08 Nov 2025 at 22:50, Ludovic Courtès <[email protected]> wrote:
> To make sure we’re all on the same page, there’s a deprecation policy > that defines how we handle these things; the recently-added > ‘define-deprecated-package’ macro that should help third-party channel > maintainers learn about upcoming deprecations: > > https://guix.gnu.org/manual/devel/en/html_node/Deprecation-Policy.html My message was assuming we follow such policy. :-) Quoting the “Deprecation Policy“: There is no formal deprecation mechanism for this case, unless a replacement exists, in which case the define-deprecated-package macro mentioned above can be used. The only mean to know what will be removed is to… browse Issues and Pull Requests, as explained by the Note. Note: Learn about pending package removals by checking issues and pull requests with the ‘deprecation’ label. Today, that’s not affordable! Or as a member of guix-science maintainers, do you volunteer for this task? :-p The main issue of third-party channel when removing is about the removal of the symbol: It breaks the third-party channel itself! As I wrote [1]: For now, the propagation of package removals to third-party channels is far to be polished. People are working on it but we are not ready yet. and for example, see https://codeberg.org/guix-science/guix-science/issues/255 Well, you know better than me. :-) Now, if ’define-deprecated-package’ is introduced to master at the beginning of the one month grace period – or some days after opening an Issue or a PR announcing the removal – this would help third-party channel to easily be in touch. It would avoid to browse the pending package removal list then cross-check the impact on the third-party channel: Third-party channel CI would list the deprecation warnings. Maybe it’s what you’re suggesting with: the recently-added ‘define-deprecated-package’ macro that should help third-party channel maintainers learn about upcoming deprecations: All that to say, all the janitor work done these days is great! And pushing on Friday or Saturday is better than not pushing at all. :-) I’m on this page. Somehow, I’m asking a kind of favor or friendliness about the very specific case of “package removal”; where the process isn’t fully formalized (yet?), BTW or IIUC. Cheers, simon 1: Avoid to push package removal on Friday? Simon Tournier <[email protected]> Fri, 07 Nov 2025 14:17:47 +0100 id:[email protected] https://lists.gnu.org/archive/html/guix-devel/2025-11 https://yhetil.org/guix/[email protected]
