Hi Andreas, it is good to have this formalized, so the GCD is welcomed. Couple of questions below.
Andreas Enge <[email protected]> writes: > ## Removal of outdated libraries which are leaves Compared to the broken packages, this section raises an interesting question, how will these libraries be located? Simply when someone notices? Or e.g., any leaf package that has package of the same name, but larger version? > The balance is different for packages than can still be built, but that are > outdated in some sense (because they are abandoned upstream or for which we > have another, newer version in Guix). It makes sense to distinguish between > packages that serve mainly as inputs to other packages (for lack of a better > word called *libraries* in the following, although their exact nature may > depend on the programming language) and packages that users frequently > install into their profiles (called *applications* in the following). > The distinction is not always obvious; for the sake of this GCD, > for instance, we treat compilers as libraries. > > Removing an outdated, but still building library that is a leaf in the > dependency tree has almost as little impact as removing a broken > package. I am not sure I agree here. Users can have local packages that depend on those libraries, so after the library removal their home environments could no longer build (for example). As long as the variable is public, I do not see any difference between a library and an application. > On the other hand, keeping the library also has little impact beyond > wasting build farm capacity. > > We follow the same removal process as above, but the initial removal > notification is prolonged from one week to three weeks. I do not object too strongly here, although I prefer to keep working code around, as long as it is working. I just want to make sure the premise for your position here is correct, and I am not sure it is (see the above). > ## Moving packages between modules > > As the Guix package collection expands, it may become desirable to > reorganise the packages into different modules: For instance, an > initial science module grows over time, and turns out to be more > manageable when split into physics, chemistry and so on. > At a first glance, this resembles package renamings, since the > concatenation of a module and a package name, such as in > `(gnu packages chemistry) molequeue`, can be considered as the fully > qualified package name. However, `deprecated-package` cannot be used, > since it may lead to circular dependencies between modules and thus break > compilation; also deprecating a package by one with the same name leads to > nonsensical warning messages suggesting that a package is superseded by > itself. > > Instead, moving a package from one module to another is akin to a removal > immediately followed by an addition. It is handled by the removal procedure > above with a one week initial notification period. Is there a way for me, as a channel maintainer, to have a single commit that works with Guix both before and after the package move? For example, I get a notification that package `foo' will be moved from `(gnu packages bar)' to `(gnu packages baz)'. What now? What changes do I make to ensure no issues for users of my channel? > # Drawbacks and Open Issues > > The GCD aims to strike a balance between making changes easy for packagers > to quickly and constantly improve the package collection, and minimising > disruption to users and channel maintainers. The discussion period will > show whether this has been reached. > > The procedure for notifying channel maintainers (and interested users) > is not fully thought out yet. Is it possible and manageable to add a > potentially large number of Codeberg accounts to a team without giving > them privileges in the Guix repository? Could this team be notified > automatically for deprecation issues without being mentioned explicitly > in the issue body? Are there alternative or additional ideas for > notification that would not add a burden on packagers trying to deprecate > packages? A simple bot that looks for issues with deprecation tag, and sends an email to guix-deprecation mailing list? Interested parties can then subscribe to that list. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
