[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Organizing packages
From: |
Jesse Gibbons |
Subject: |
Organizing packages |
Date: |
Tue, 9 Jul 2019 10:07:32 -0600 |
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
- Organizing packages,
Jesse Gibbons <=