Hi @muflone, Thank you for your reply. There was an argument for having these packages for tracking system library dependencies and aiding their installation. But for that purpose, a meta package is better, one which does not itself provide the target runtime/sdk.

A workaround exists using pacman --assume-installed

I think it is still better to have a valid library dependency installed in system for downstream consumer packages installed in system. If a package exists either in Arch repo or on AUR, and that one calls for having an Android platform/SDK/runtime etc. installed, I think it is logical to serve that need by having the needed library installed in the system as well. Or one can take it up with the package owner to discuss if that particular depends is really needed or can be an optdepend instead. Arch guidelines already call for large packages to be put in /opt - which could be hosted on a big storage volume outside of the root volume. As of now, AUR has many different versions of the Android platform runtimes and SDK's. It does not seem too prohibitive to have such packages for every needed version on AUR. (Also, a user can quickly modify a PKGBUILD to install another version locally, if that version is not submitted to AUR and the user sees not much benefit in submitting that particular variant.) Also, having an arbitrary number of different platform and sdk versions in home is good for development, but AUR users are not all developers - and at least, most of them are not developing/testing Android applications. 'android-platform' itself might have less non-dev consumers, but even it is required as a makedepend by scrcpy-full-git, and not every AUR user builds in chroot, despite that being the gold standard. In contrast to 'android-platform', there are many AUR packages that rely on 'android-tools', e.g. adb, to interface with connected devices. Those runtimes should be guaranteed to be there in the system and not depend on what the user installs or doesn't install in home dir. So in that case, a dummy package is more potentially breaking many "consumer grade" packages during runtime. I might be a purist and a stickler for consistency in dependency management, so maybe that's why I feel that dummy packages are a hack to escape the constraints and requirements of a strict graph that was designed to be strict because that is the purpose and the usefulness of the package management system that implements it. (And a "provides" name is like an API/ABI name, and therefore is a "contract promise". Dummy packages lie about guaranteeing the fulfilment of that promise.) Outside of that strict network of managed packages, e.g. in the user's home folder, there can be anarchy, with the benefit of lack of bureaucracy. But the two worlds don't mix and match well in the direction of "system executable/library depends on user/home library runtime". Thank you for taking this up for consideration. Cheers, Marcell (MarsSeed) On 15 October 2023 13:45:40 GMT+02:00, Muflone <muflone@archlinux.org> wrote:

Hi

...

No one forces anyone to install Android IDE's and Android SDK's / platform tools 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.

There are many packages in AUR requiring android-platform or android-sdk and both can be provided by user side simply downloading them using the Android SDK Manager, it's also written in the package comments what are the reasons behind these packages.

...

On 15 October 2023 12:15:04 GMT+02:00, notify@aur.archlinux.org wrote:

...

MarsSeed [1] filed a deletion request for android-platform-dummy [2]:

According to some TU's, dummy packages are not allowed on AUR.

I don't know why this one would be particularly useful.

I don't have a strong opinion about dummy packages, for sure there must not be a reason to duplicate every packages as they could be provided by user side, of course. Android packages are somewhat special as they are really huge. As developer I had tens of android platform versions and the same for the android SDK and system images.

At the same time I have nothing against the deletion if they are not useful for many people but for my opinion they are useful (I'm not accepting or closing the request for the moment). A workaround exists using pacman --assume-installed

I think the dummy packages argument worth a separate discussion in aur-general, not just a couple TU's opinion

Best regards