Hi, On Thu, 21 Aug 2025 14:55:56 +0900 Maxim Cournoyer <[email protected]> wrote: > Don't we already have a deprecation policy? What's missing from it? > I don't think a GCD is needed to adjust our policy, if needed, > especially if it's to relax it.
The policy is in "22.17 Deprecation Policy"[1]. Maybe the manual misses advises on how to fix packages that fail to build with proper rationales, ideally for packages with no new release yet. For instance for a C/C++ program, one of the fix could be to use an older GCC in the dependencies to build the package, but I assume that this isn't the way to go as I didn't stumble on examples of that. Other ways could be to: - pass CFLAGS / CXXFLAGS (like -Wno[...]) to configure - add patch(es) to fix the build, - update the revision to something not yet released if the packages fetches code from version control I guess that in some cases it depends on the specifics to understand which one is best, but there are probably some bad answers (like use an older compiler) at least for some situations. The other issue is that we're not supposed to break things in the first place[2]: > 5. Make sure the package builds on your platform, using guix build > package. Also build at least its direct dependents with guix build > --dependents=1 package (see guix build). So while it doesn't directly conflict with the Deprecation Policy, things could also be clarified a bit as for when it is okay to break the rule above. This could all be clarified in the manual if there is some interest to do that, and if the rationale are included as well either in the change itself or in the commit message, there would probably be no need for a GCD, assuming that people agree with the rationale and so on. References: ----------- [1]https://guix.gnu.org/manual/devel/en/guix.html#Deprecation-Policy [2]https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches Denis.
pgplGx0Y3YsOW.pgp
Description: OpenPGP digital signature
