Add RFC 12: Forbid dummy packages from AUR
Reject AUR packages that fulfill package dependencies without providing the files/binaries of the package in question.
Merge request reports
Activity
An alternative to such dummy packages is using pacman's
--assume-installed, but it is not available as a configuration option (FS#73114).
rfcs/0012-forbid-dummy-packages-from-aur.rst 0 → 10064488 arch=('i686' 'x86_64') 89 license=('custom:MIT') 90 depends=('apulse') 91 provides=('pulseaudio' 'pulseaudio-alsa' 'libpulse' 'libpulse.so=0-64' 'libpulse-simple.so=0-64') 92 conflicts=(${provides[@]}) 93 94 package() { 95 mkdir -p ${pkgdir}/usr/lib 96 for lib in libpulse-mainloop-glib.so libpulse-simple.so libpulse.so 97 do 98 ln -s apulse/${lib} "${pkgdir}/usr/lib/${lib}" 99 ln -s apulse/${lib}.0 "${pkgdir}/usr/lib/${lib}.0" 100 done 101 } 102 103 Would this be deleted or instead renamed to e.g. pulseaudio-apulse-shim? -
Shim packages like this one generally are completely fine in my opinion: this is not a dummy package at all, but a compatible implementation of the PulseAudio API using a different technology. Since it contains the necessary libraries to do this, providing the packages it is able to replace seems appropriate. However the name of the package is terrible and must be changed to refer to apulse instead of using a nondescript
-dummysuffix.I fully agree with the proposal of this RFC to forbid empty dummy packages: as far as I can see, there is only one reason for the existence of such a package, which is that the dummy package fulfils a required dependency of another package that is not really a hard dependency. This is a packaging error on the part of the other package and should be solved by making the dependency optional. The AUR is no place to provide hacky workarounds like this, file a bug report or leave a comment on the problematic package instead.
In all other cases, a dummy package removes a required part of the system and will result in some form of breakage. While users are free to break their own system in private, these things have no place in the AUR.
I maintain
base-devel-meta. I actually don't think this proposal is a bad ideal, but I'd love to see an officialbase-develpackage with the same dependencies (much like we already have abasepackage).-
In my understanding this RFC does not cover actual meta packages, i.e. empty packages that depend on other packages, but do not provide them. Unlike dummy packages (empty packages that only provide another package, for the sole purpose of being installed in place of the other package), I can see a general usefulness of meta packages and would not be in favour of outright banning them: of course we don't want meta packages of the form
diabonas's-collection-of-useful-packagesin the AUR (because they wouldn't be useful to many people), but a meta package tracking thebase-develgroup seems fine to me. Whether thebase-develgroup should be replaced by a meta package in the official repositories would be the subject of a different RFC though ;)
- rfcs/0012-forbid-dummy-packages-from-aur.rst 0 → 100644
35 checkdepends=() 36 optdepends=() 37 provides=("ttf-font-nerd") 38 conflicts=() 39 replaces=() 40 backup=() 41 options=() 42 install= 43 changelog= 44 noextract=() 45 validpgpkeys=() 46 47 This package serves no functional purpose; It exists to satisfy a dependency 48 without having the files installed on the system. This allows the user to 49 install other packages without having to include a larger, unwanted package on 50 the system. - Comment on lines +47 to +50
This is missing the motivation for why these packages should be removed.
It says these packages serve no "functional" purpose but then says they do serve a purpose; preventing the inclusion of packages a user does not want. It goes on to say that these packages are "relatively harmless".
The chance a user accidentally installs one of these dummy packages is pretty low imho. And if the user breaks themselves, they went out of the way to do so.
Especially in the AUR which is much more open about what is allowed, why should there be a official policy to enforce the removal of such packages?
-
While the AUR is a more open place than the official repositories, it does have rules that all packages uploaded there must adhere to in the form of the AUR submission guidelines.
In my opinion, dummy packages as described in this RFC already fail the general rule that packages uploaded to the AUR must be useful to more than a few people, see also my other comment. However this rule is obviously subject to interpretation, so providing more explicit examples of unwanted types of packages seems useful to both AUR maintainers and users.
From a practical moderation standpoint, allowing dummy packages would mean that potentially any non-leaf package could be duplicated as a dummy package because someone might not want to install this particular dependency for some reason or another. Obviously this is not feasible, and deciding which dummy packages might be useful and which ones are not seems more difficult (and very subjective) than generally forbidding all packages of this type given their very low usefulness.
From a practical moderation standpoint, allowing dummy packages would mean that potentially any non-leaf package could be duplicated as a dummy package because someone might not want to install this particular dependency for some reason or another
For me, this is often due to an official package having a dependency that actually breaks.
lsddepends on an icon font that renders mis-sized onalacritty. Removing the package makes it work. Thedummypackage keeps the dependency sane.I'm sure many common usages are because of issues like this: packages included in
dependsthat are not strict dependencies.-
Please see my other comment on this subject: the cases you are describing are issues with the official packages that should be reported as such in the bug tracker. Workarounds like using a dummy package are fine for your personal use, but have no place in the AUR, for the same reason that uploading updated PKGBUILDs for outdated repository packages is forbidden.
