Hi MarsSeed, (Resending because my previous email was blocked due to not subscribing to the list yet and the moderators didn't approve it in the past few days.)
I respectfully disagree with the request here (and the other ones for android-sdk-dummy and android-sdk-cmdline-tools-latest-dummy). Please see my comments inline. > Dummy packages are not useful to provide to a package manager, and > they are not allowed on AUR. > > Having a dummy package installed defeats the purpose of using a > package manager. There are always package distributions that don't fit within the standard package management, which is shown by the existence of the /opt directory. > If a package requires another package, there's a good reason for it, > and both should be installed in the system for them to work. I don't think so, there are packages that may depend on these Android tools, and these dummy packages can provide that dependency for them, as a valid alternative to installing the original package. e.g., a number of packages may provide adb, and one may want to use the (more up-to-date) version from the official Android SDK. > No one forces anyone to install Android IDE's and Android SDK's / > platform tools they use for development into the system. They can live > happily inside the user's home folder as well. In that case, the user > is not using pacman to manage those installations. They can live in user's home directory, but they don't have to. Having them live inside /opt/ brings the additional benefit that it can act as a valid alternative dependency for other packages, and that it can be (almost) always usable/used by everything else in the system. These dummy packages also help a lot in holding and tracking the dependencies of the actual content, which may be prone to be uninstalled or at least hard to manage without such a dummy package. They may also provide useful system level configurations, e.g. systemd service definitions. > If an AUR package requires Android SDK platform tools, both should be > managed by the package manager. Developers have to ensure that they > have sufficient storage space on their system for their particular > developer activity, and disk space is not that expensive nowadays. I don't see a reason that they absolutely have to be both managed by the package manager. And I don't think it's about disk space (I agree with you that disk space is less of a problem), but more about allowing alternative versions of the dependency (even if it lives under /opt/ and is updated outside package manager for convenience). All in all, the philosophy of Arch Linux includes pragmatism & user centrality, and I believe in this case keeping these dummy packages for Android SDK is well justified for that considering the rationale above. So I hope you would be okay with dropping these deletion requests.
