Hi MarsSeed, I respectfully disagree with the request here (and the other ones). Please see my comments inline. <notify@aur.archlinux.org> 于2023年10月15日周日 03:28写道：

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

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 doesn't fit with the standard package management, which is explained 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 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 helps a lot in holding and tracking the depdencies 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.

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.