I noticed that a few files have only one package definition and are named for that package. I think these packages can be organized better. Might I suggest the following rules:
1. if a package is a library for a particular language $LANG (like Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library built for a particular PURPOSE, it may go into LANG-PURPOSE.scm with those packages. 2. If the package defines a compiler or interpreter for a language $LANG, it may go into ${LANG}.scm 3. If the package is part of a large divisible project $PROJ like gcc or texlive, it may go into ${PROJ}.scm 4. If the package is maintained a part of a large desktop environment $DE like GNOME or KDE, it may be put in ${DE}.scm 5. When in doubt, the package must go into a file named after its $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game (like supertuxracer), it goes into games.scm; if it is for undirected fun (like sl), it goes into toys.scm; if it is for audio control or audio production, it goes into audio.scm; if it is for drawing or producing graphics, it goes into graphics.scm; etc. Projects that can be described with multiple purposes (like fortune) may go into any of those files. I think this will make searching easier because not everything has an obvious name, and when I `guix search` for a purpose (like drawing) I often get unrelated results. If we follow these rules: - Most packages will remain in place, especially libraries upon which plenty of packages depend. - Packages that are placed in their own files should be moved to a file that describes their function. For exaple: - abduco.scm only defines abduco, a program that lets child processes of a shell become independent. It might fit into task-management.scm or moreutils.scm. - abiword.scm only defines abiword, a word processing program. It may be placed into a new file office.scm. - acct.scm only defines acct, which based on its description might fit into admin.scm - acl.scm only defines acl, which based on its functionality fits into admin.scm. - anthy.scm only defines anthy, which is useful for Japanese language input. It can fit into language.scm. I hope you can see the pattern, and perhaps you can find better places for some of these packages. By my count, there are currently over 140 of these files that define only one package. - Files that define multiple packages and are named after one app might be split into multiple pieces by function. For example, libreoffice.scm defines, among other packages, libreoffice, which can go into office.scm, and multiple dictionaries, which can be moved into the already-existing dictionaries.scm. To me this is lower priority than one-package files. - When a package is moved, the associated copyright information should be copied with it. This might make it difficult to split files like libreoffice.scm. I do not think the people who move packages should add their copyright information because they are not really adding new code, but I leave this detail to community discussion. - Ideally, packages would be alphabetized within their respective files. This might not be practical. - Services should likewise be organized by function, with file names consisting of full words. Although there is not much to do on this front, it will likely break a lot of OS configurations and make the manual inaccurate. Therefore it is very low priority to me. Feel free to tell me what you think of this suggestion. If the maintainers and the community like this idea, I will personally work on carrying it out. I am also ready to openly discuss particular packages, either in response to this or when I send a patch. -Jesse