On 27 February 2024 21:01:27 GMT+01:00, not...@aur.archlinux.org wrote: >Request #48969 has been Rejected by serebit [1]: > >If the package is outdated and unmaintained, but the upstream is still >active, please request orphan rather than deletion.
Hi Campbell, Thank you for your feedback. I'd like to share some more background on this package. This has already been an orphan by the time you evaluated the requiest. The problems about keeping it are numerous. It is missing 3 dependencies (2 of them are transitive) MISSING python-sphinx-testing MISSING python-confluent-kafka MISSING python-sqlalchemy-migrate And 90% of the following AUR dependencies are abandoned for 3 years and are from same maintainer, and several of them are also broken: AUR DEP python-reno AUR DEP python-os-api-ref AUR DEP python-sphinx-feature-classification AUR DEP python-flake8-import-order AUR DEP python-flake8-logging-format AUR DEP python-restructuredtext_lint AUR DEP python-doc8 AUR DEP qemu-git AUR MAKE python-qpid-proton AUR MAKE python-pyngus AUR DEP python-futurist AUR DEP python-yappi AUR DEP python-oslo-service AUR DEP python-oslo-metrics AUR DEP python-statsd AUR DEP python-oslo-middleware AUR DEP python-oslo-messaging AUR MAKE python-etcd3gw AUR DEP python-zstd AUR MAKE python-pymemcache AUR DEP python-oslo-cache AUR DEP python-pycadf AUR DEP python-keystonemiddleware AUR DEP python-oslo-policy AUR DEP python-oslo-privsep AUR DEP python-oslo-reports AUR DEP python-oslo-rootwrap AUR DEP python-oslo-upgradecheck AUR DEP python-oslo-versionedobjects AUR MAKE python2 AUR MAKE python2-setuptools AUR DEP python-suds-jurko AUR DEP python-oslo-vmware AUR DEP python-barbicanclient AUR MAKE python-zake AUR MAKE python-pydotplus AUR DEP python-automaton AUR DEP python-taskflow AUR DEP python-rtslib-fb AUR DEP python-castellan AUR DEP python-os-win AUR DEP python-os-brick AUR MAKE python-sysv_ipc AUR MAKE bump2version AUR MAKE python-etcd3 AUR DEP python-tooz AUR DEP python-cursive As I've stated, this is a cloud server component application, and requires frequent updates (there are several module updates in month in its dependency chain). It's deployment is best managed automatically, and PyPI is an ideal source for the modules. None of the abandoned packages from submitter have comments or votes on AUR. Only I flagged them for updates. So what's the benefit in keeping them? Together with the other openstack-* packages from same submitter, they have an AUR dependency chain of 100 python packages, the majority of which are from same submitter and also abandoned since 3 years ago. Take into account also that many openstack-client-* Python packages with their specific dependencies are in Arch repo, but their update cadence is irregular. Which means that an AUR maintainer couldn't just automate updating the AUR packages in a "dumb" way, pushing every update bump that upstream publishes, because the AUR packages also have to stay on versions that are tested and compatible with the repo version of their dependencies. Deleting them now would not harm anyone. Given that only robust and Arch Linux specific CI testing based automation would be a practical and viable way to maintain these packages on AUR, if ever someone decided to set up such a system, they can immediately push their PKGBUILDs to AUR and (re)create the missing packages. But until that time, they are just a 100 dead weight items on AUR. So again, can you say what are the strong arguments in favor of keeping them, given the current situation? Thank you in advance for your valuable guidance on this. Cheers, Marcell / MarsSeed
