Organizing packages

[Jesse Gibbons]

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