Better package naming conventions
💡
Idea proposal
✔ ️
Checks NOTE: The below check boxes must be checked before the accompanying idea will be considered.
-
I have checked that the idea is not directly tied to a specific project For example: "Show label icons in the package overview web page" must be a feature request in the ArchWeb repository -
I have carefully checked this idea is not already covered by any open or closed ideas. -
I understand that I hold no copyright claims and that this idea can be adapted and used by Arch Linux in any arbitrary shape or form.
❔
Summary Arch Linux packages should have a good/more informative naming convention
🔥
Motivation The current naming convention is pretty unclear. For example if I look for gnome secrets, the package i have to install is gnome-passwordsafe. The actual appID of it is yet something completely different "org.gnome.World.Secrets" and the startup command is just "secrets". So from package name you can't even guess on what you have to run later on. This is the most bad example I could find, but still a valid example.
Another problem is that on install time we have no real information about where packages come from. This might not be a huge thing for most parts, but in case of package names as "code" it absolutely is. Why is microsoft visual studio code packages as code
, kdevelop is kdevelop
but gnome builder is packaged as "gnome-builder"? What if I build a tool that I also would call code, would it become something-code, code-something, and why would it be that?
A clear naming convention would help a lot.
What would it change?
- General package names would be more consistent
- The switch of a package to the source of a fork or new maintainer/project would mean a replace instead of a hidden switch
- Would allow to filter packages by provider
Specification 🧾
There are currently essentially 2 implementations I know of to tackle that.
- Reverse domain name notation (RDNN) That is used by dbus, appstream and freedesktop supporters like gnome and KDE
-
Microsoft Winget package Identifiers(MWGPI), used by winget
😉
No-No?
While I'm a supporter of the the reverse domain name notation, I think it's not really usable for a package management. You'd need to track for domain name changes, like if someone moved from github to an own site, but the package doesnt actually have a new version.
So com.gitlab.fabiscafe.scriptcollection 23.05 would be replaced by cafe.fabis.scriptcollection 23.05. Not logical at all and that's something many people don't like about flatpak, where this is a thing.
Yes!
What Microsoft does in Winget is much more approachable to build on top of.
As example:
code
would become microsoft.vscode
because it's the opensource edition, while the binary one from microsoft would be microsoft.visualstudiocode
. Alternatively it could be microsoft.vscode.oss
. On the other hand kdevelop
would become kde.kdevelop
and gnome-builder
would become gnome.builder
⚖ ️
Comparison Current Name | RDNN | MWGPI |
---|---|---|
code | com.github.microsoft.code | microsoft.vscode |
visual-studio-code-bin | com.visualstudio.code | microsoft.visualstudiocode |
firefox | org.mozilla.firefox | mozilla.firefox |
discord | com.discord | discord.discord |
gnome-builder | org.gnome.builder | gnome.builder |
openssl | org.openssl | openssl.openssl |
linux | com.github.archlinux.linux | archlinux.linux |
linux-zen | org.zen-kernel | zen-kernel.linux.zen |
This way extensions as language support can be set as
Current Name | RDNN | MWGPI |
---|---|---|
firefox | org.mozilla.firefox | mozilla.firefox |
firefox-i18n-fi | org.mozilla.firefox-i18n-fi | mozilla.firefox.i18n.fi |
firefox-developer-edition | org.mozilla.firefox-developer-edition | mozilla.firefox.developeredition |
firefox-developer-edition-i18n-fi | org.mozilla.firefox-developer-edition-i18n-fi | mozilla.firefox.developeredition.i18n.fi |
firefox-esr | org.mozilla.firefox-esr | mozilla.firefox.esr |
firefox-esr-i18n-fi | org.mozilla.firefox-esr-i18n-fi | mozilla.firefox.esr.i18n.fi |
So here in some cases it's not very clear on how to go with RDNN, as the languages are not really covered by an own domain. With MWGPI however there is a pretty clear path.
🏗 ️
The Composition As said earlier, I'd rather go with the more logical MWGPI, So I ignore RDNN for this part
the package name in the PKGBUILD would be like
pkgname=<provider>.<softwarename>[.<extension>(.<info>)]
Where
- provider defines the company, project, person distributing the source.
- softwarename defines the actual name of the software, how it is called.
-
extension defines for example localization packages, actual extensions or add-ons. As example
firefox-noscript
would becomenoscript.firefox.noscript
-
info defines wider information about what it is. Here it would be the place to put the git,svn,bin,[…] extent to.
devtools-git-poc
->archlinux.devtools.git.poc