If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
openSUSE:Package group guidelines
The Group: line in .spec files is a freeform text field that is used to declare categories that a browsing application can sort packages by.
Historically, the Group: field value specified exactly one category out of a hierarchially-ordered tree of many categories such as:
- CAD (3D)
A category is written down as the path into this tree using slashes as separators, in other words, Template:Amusements/Games/3D for a 3D game, or Template:Amusements/Games for a less-specific kind of game.
Because a package may fit into multiple categories, a 2019 proposal was made to move away from the hierarchial system and instead use a tag system as a base, wherein the Group: field is a space-separated list of keywords that characterize the package. This way, the kate package for example may be associated with the keywords kde and editor and the gedit package with gnome and editor, such that a user browsing the software catalog can filter either by kde or gnome (depending on preference), or by editor (if it does not matter which UI) to discover packages he might be interested in. The reader is hereby referred to the sites of freshcode.club and stackexchange.com as example of practical uses of such a tag system.
- 1 Tag-based system
- 2 Classic hierarchial group system
- 2.1 Amusement
- 2.2 Development
- 2.3 Documentation
- 2.4 Hardware
- 2.5 Meta packages
- 2.6 Multimedia
- 2.7 Productivity
- 2.8 System
Experiments have shown that the words from the classic group list make for a good start. Note that spaces separate tags now, so what was previously spaces has been turned into dashes where needed. Based on that, the current suggestive list is:
3d 3d-editor action amusement arcade archiving astronomy background backup base benchmark bitmap-editor board boot browser building c c++ cad cd camera card chemistry chess chinese korean clock clustering compression computing console dns daemon database debugger development diagnostic dictionary displaymanager doc-generator docbook documentation editor converter electronics email emulator fax fhs file-sharing file-utility filesystem finance fonts fortran frontend ftp gnome gui gui-builder game go graphics h323 ha html hamradio hardware haskell howto i18n icq ide irc isdn instant-messenger japanese java joystick kde kernel ldap lxde library localization logging logic lua manuals management mathematics metapackage midi mixer mobile modem monitoring multimedia nfs nis navigator networking news nodejs ocaml office organizer pdf php ppp ps palm parallel perl physics presentation printing proxy publishing puzzle python rpg race radio radius raytracer real-time routing ruby rust sgml sip ssh samba satellite scanner scheme scientific screensaver security server shell shoot simulation sound sources spell spreadsheet strategy tv tcl tex teaching telephony terminal texinfo text toys turn-based ups utility vector-editor version-control video viewer visualization wayland web wifi word word-processor x11 xfce xml yast
Custom tags can be used, there are generally no "wrong" tags. The field is, after all, free-form. When analyzed by a computer program, tags should be treated as case-insensitive and no particular order should be assumed. For consistency, lowercase-throughout is suggested for use in spec files, similar to stackexchange and tag clouds.
- How will the tag system deal with typos?— A histogram of all the tags used in the distro can readily be built. The tail end of that where the low-use values are located. The package(s) in question can then have offending tag be changed to a more common value.
- What tags should be added for a package?— The package maintainer is supposed to have a very coarse idea of a package's target in the first place. Suggestions for further tags can be sourced from catalogs like freshcode.club (if there is an entry for the software), from the Category field of .desktop files (if so present in the source archive), from the <project_group> XML tag of AppData XML files, or any other source that gives an idea of what a software is meant to be used for.
- System/Libraries has no equivalent in tag space. This group was assigned for runtime dependencies that are automatically installed and generally not specifically selected by an end-user. As a result, the Group: line for these subpackages remains empty (the line is removed altogether).
Classic hierarchial group system
There used to be times when the Group: field was checked by the rpmlint build software for conformity with specific values. This has been abolished (again) in September 2019. New groups can be created by just starting to make use of them in .spec files. The below list is a suggestion of classic groups to use — but preferably, you should go for tags.
- Amusements/Games/Strategy/Real Time
- Amusements/Games/Strategy/Turn Based
Teaching contains things that are educational. So most of the applications in this group are useful in schools, but not necessarily universities.
Contains things that entertain users but are not real games.
This section has been created to help software developers. Normal users should never need to select packages from this group manually. The librariesTemplate:Which must be installed to run applications, but they are installed automatically due to dependencies.
The following groups are intended for tools that are useful or even necessary for developing in a particular programming language. This is the right place for compilers, interpreters, and programming language–dependent tools.
- Development/Languages/C and C++
The following groups are intended for packages that allow developing with a library. They are primarily sorted by programming language. However, there are also special groups for KDE, GNOME, and YaST libraries. Here, developers should find all available libraries that can be used in more projects.
If a library can be attributed to a specific RPM topic, use it. For example, the ntl library focuses on specific aspects of number theory, and so under Productivity/Scientific/Math, while a general-purpose library like libHX is in the fallback group Development/Libraries/C and C++. For packages that fall inbetween two groups, pick the one that is less abstract, e.g. pick Math over Libs/C++.
The -devel subpackage is generally put into the group Development/Libraries/(Subgroup), depending on language. The subpackage providing the shared libraries located are generally marked as System/Libraries. Note that some packages also having programming as a topic use Development/Languages/(Subgroup) instead — and that they are not as consistently used as one could wish.
Development/Languages/Perl *.spec -> 29 Development/Libraries/Perl *.spec -> 1127 Development/Languages/Python *.spec -> 1190 Development/Libraries/Python *.spec -> 404
A potential -doc subpackage is put into the group Documentation/(Subgroup).
- Development/Libraries/C and C++
- Development/Sources is intended for binary and noarch packages containing sources. It is the right place for kernel sources and kernel module sources.
Groups from this section contain tools useful for developing that are not connected to a particular programming language.
- Development/Tools/Doc Generators
- Development/Tools/GUI Builders
- Development/Tools/Version Control
The Documentation section is intended for all packages with documentation that is put in an extra package.
- Documentation/Howto: a particular kind of documentation ("to accomplish X, do Y,Z")
- Documentation/HTML: the documentation consists of mostly HTML-formatted files
- Documentation/Man: the documentation consists of mostly roff/troff/nroff-formatted files, or have the particular written style of a program manual page ("option X allows to set Y")
- Documentation/Other: anything else
- Documentation/SUSE: documentation pertaining to the SUSE/openSUSE Linux distribution
The Hardware section contains tools supporting a special hardware.
- Metapackages: this group contains packages with should normally not end up on any installation source. They contain files which should end up on the media itself, like README.txt, License files, documentation or DOS utilitiesTemplate:Wtf.
The groups "Multimedia/*" came in from jpackage. See Productivity/Multimedia/* instead.
The Productivity section is huge and is intended for the packages most important to the average user: the applications used to produce something.
Groups within this section are intended for tools for basic operations with files. These are packages like file, findutils and file managers like mc, nautilus or ytree.
- Productivity/File utilities
- Productivity/Graphics/3D Editors
- Productivity/Graphics/Bitmap Editors
- Productivity/Graphics/Convertors (Converters?)
- Productivity/Graphics/Vector Editors
Groups from this section are intended for Linux ham radio (Amateur radio, often AX.25) applications and related utilities.
- Productivity/Multimedia/Sound/Editors and Convertors
- Productivity/Multimedia/Video/Editors and Convertors
Groups from this section are intended for packages providing various networking services and related tools.
- Productivity/Networking/Instant Messenger
- Productivity/Office/Word Processor
Groups from this section are intended for packages used to publish information. The applications from this group usually need more experienced users than similar applications from the Office section.
If it matters in university or similar education paths, this definitely seems like the place for it, though of course you won't necessarily be needing the understanding of the inner algorithms to use the software — or these example RPM groups.
Groups from this section are intended for security related stuff like virus scanners, safe password generators, utilities for encrypting, decrypting, signing data, and permission settings (e.g. the permissions package).
The packages in the System subgroups make up the base of the operating system. They are important for the system administrator and the normal user should not need to know much about them. They only make an environment in which to run applications from other groups, like * Productivity or * Amusement.
- System/Base is intended for the base system tools. It includes packages like eject, systemd, man, sed, sudo, tar and ulimit.
- System/Benchmark is intended for packages providing benchmarks and various test suites.
- System/Boot is intended for tools related to system booting. It contains packages with boot loaders, image builders, boot splash themes, memory test, etc.
- System/Console is intended for console-specific packages like fbset, gpm, kbd and vlock.
- System/Daemons is intended for the base system daemons. These are packages like at(d), autofs, nscd, powersave or syslogd.
- System/Fhs is intended for packages creating the base directory structure according to FHS (File Hierarchy System). These are packages like filesystem, aaa_base or devs.
- System/Filesystems is intended for file system–related tools. These are packages like * quota, * dosfstools, * reiserfs, * reaidtools, and * xfstools.
- System/Kernel contains kernel binaries and kernel-related tools like module-init-tools. The packages with kernel sources and kernel modules sources are in the group Development/Sources.
- System/Libraries is intended for packages providing the part of libraries necessary to run applications. Packages in this group should already be installed automatically because of a dependency. Therefore, this group ought to be never used for the main Group: line of a .spec file (since the libraries ought to be in a subpackage, see SLPP). Neither users nor developers should need to search for packages in this group. This means that these must not provide any application — such packages must be in the section Productivity.
- System/Localization contains language specific subpackages which are split off a main package. In openSUSE 10.3 and up, this is done automatically using the %lang_package macro in the specfile.
- System/Management is intended for various GUI, text, or web-based tools used to manage the system. However, the YaST modules have their own group, System/YaST.
- System/Monitoring is intended for tools monitoring the system directly or by analyzing logs.
- System/Packages: for packages related to package management, like alien, deb, or rpm.
- System/Sound Daemons: intended for sound daemons despite they can be primary developed for a special usage. For example, there are sound daemons for GNOME esound or WindowMaker wsndsrv.
Groups of this section are intended for emulators of various operating systems. Packages like dosemu, wine (but that's not an emulator), vmware or atai800 are found here.
Groups from this section contain window managers and related tools. Some window managers have their own specific variants or ports of applications, but this group is not for applications or libraries. Such packages should be put in sections like Productivity, Development, or Amusements.
Groups from this section are intended for packages providing special support for entering, displaying or working with Chinese, Japanese, and Korean langauges.
Groups from the X11 section are intended for the base graphical system, and this also includes X11 successors currently (Wayland, Mir, etc.). Window managers go into System/GUI.
The System/YaST group is intended for all YaST-related packages. All YaST modules especially should be put in this group.