[aur-requests] [PRQ#26744] Deletion Request for octoprint-venv
Repentinus [1] filed a deletion request for octoprint-venv [2]: Installs octoprint into a venv instead of the appropriate FHS location. Should be fixed and uploaded as octoprint. [1] https://aur.archlinux.org/account/Repentinus/ [2] https://aur.archlinux.org/pkgbase/octoprint-venv/
On 28.06.21 20:08, notify@aur.archlinux.org wrote:
Repentinus [1] filed a deletion request for octoprint-venv [2]:
Installs octoprint into a venv instead of the appropriate FHS location. Should be fixed and uploaded as octoprint.
The package installs into /opt, which is the appropriate FHS location for self contained packages (like a full venv). So what exactly do you want to "fix" here? If you dislike the general approach of using a venv then just contribute/patch the already existing 'octoprint' (no suffix) package to remove the venv there. Keep in mind that this would break often on dependency updates and therefore will be a lot of patch work. I have tried it for a while and it was just not feasible... Only real solution is to constantly help upstream with compatibility of bleeding edge dependencies. That would make this package indeed not necessary anymore. In the meantime I think a venv package is still useful, providing proper user/permissions + systemd integration with a venv installation as the Octoprint devs recommend. I am open to other ideas, but I don't see how simply deleting this would improve anything.
Request #26744 has been accepted by yan12125 [1]. [1] https://aur.archlinux.org/account/yan12125/
Apparently a package that I regularly maintained for over 3 years and was the most popular Octoprint package is not even worth a comment before wiping out. I am extremely disappointed by that reaction! Now only the 'octoprint' package is left, with the sloppy maintainer that takes multiple months for an update, does not react to comments or ood flags, still uses a install script with broken paths (python 2.7), breaks the octoprint plugin system and the best part: it also installs into a venv! So if using a venv would be really the reason for deleting my package then 'octoprint' should be deleted immediately too. For other reasons I can only speculate, maybe you think using a -venv suffix (to make clear that it includes a virtualenv) was a bad decision? But then why not just gracefully merge/rename? I guess I am shouting into a void, same as my last mail nobody reads this anyway and you almighty TUs don't care if only broken crap is left on the AUR. Makes no sense to waste anymore of my time here. On 25.07.21 04:38, notify--- via aur-requests wrote:
Request #26744 has been accepted by yan12125 [1].
On 2021-07-25 16:14, Jake via aur-requests wrote:
Apparently a package that I regularly maintained for over 3 years and was the most popular Octoprint package is not even worth a comment before wiping out. I am extremely disappointed by that reaction!
We apologize for the somewhat unceremonious deletion. It was bad form but an honest mistake and we ask for your understanding moving forward. Some of us had seen the mailing list post bringing up the issues involved, but unfortunately not everyone had and it slipped by someone that handled the flag based on what (I assume) was an innocent assumption working through flags that no comments meant no objectons. Sending the message you did to the list was the right thing to do, the TU just missed it. I believe they have sent their apologies in another message as well and restored the repository on the AUR. It is currently an orphan I would encourage you to adopt it as a starting point. Unfortunately it is not possible to restore comments or votes on the package, that data is permanently lost from out database. The best I see out there is a February snapshot on archive.org https://web.archive.org/web/20210226194034/https://aur.archlinux.org/package...
Now only the 'octoprint' package is left [...] it also installs into a venv!
This is unfortunate at best. I understand the objects to a venv package and would like to see a better solution, but in Arch's spirit of pragmatism if the only way to get it working at all is a venv we can probably accommodate that. In the mean time having a package that doesn't do what it says on the tin is even worse. I suggest: * Adopting and making sure the current -venv package works. * Filing a merge request for the misnamed package into yours, so that at least the extant packages are properly identified. Also this will clear up the current duplicate situation. If you'd like after the merge inviting the maintainer(s) of the other package to co-maintain the -venv one might be a good gesture. * That merge will also clear up the `octroprint` namespace to be used by a PKGBUILD that actually attempts to package things normally without venv. There is another mail on the list with some suggestions to that effect. How does that sound? I'm going to reject the request to delete the other package mostly to open up the way to a merge as suggested above. Regards, Caleb
On 27.07.21 10:55, Caleb Maclennan wrote:
On 2021-07-25 16:14, Jake via aur-requests wrote:
Apparently a package that I regularly maintained for over 3 years and was the most popular Octoprint package is not even worth a comment before wiping out. I am extremely disappointed by that reaction!
We apologize for the somewhat unceremonious deletion. It was bad form but an honest mistake and we ask for your understanding moving forward. Some of us had seen the mailing list post bringing up the issues involved, but unfortunately not everyone had and it slipped by someone that handled the flag based on what (I assume) was an innocent assumption working through flags that no comments meant no objectons. Sending the message you did to the list was the right thing to do, the TU just missed it. I believe they have sent their apologies in another message as well and restored the repository on the AUR.
Yeah, I can understand that. Thanks for the detailed response.
It is currently an orphan I would encourage you to adopt it as a starting point. Unfortunately it is not possible to restore comments or votes on the package, that data is permanently lost from out database. The best I see out there is a February snapshot on archive.org
https://web.archive.org/web/20210226194034/https://aur.archlinux.org/package...
That is really a shame, the comments contained valuable discussions. Though I guess putting this archive.org link into the comments works too.
Now only the 'octoprint' package is left [...] it also installs into a venv!
This is unfortunate at best. I understand the objects to a venv package and would like to see a better solution, but in Arch's spirit of pragmatism if the only way to get it working at all is a venv we can probably accommodate that. In the mean time having a package that doesn't do what it says on the tin is even worse.
I suggest:
* Adopting and making sure the current -venv package works. * Filing a merge request for the misnamed package into yours, so that at least the extant packages are properly identified. Also this will clear up the current duplicate situation. If you'd like after the merge inviting the maintainer(s) of the other package to co-maintain the -venv one might be a good gesture. * That merge will also clear up the `octroprint` namespace to be used by a PKGBUILD that actually attempts to package things normally without venv. There is another mail on the list with some suggestions to that effect.
How does that sound?
Someone else already adopted the -venv package in the meantime, so it is probably taken care of now. I might still (co)maintain if there is a need. Agreed, merging would make sense, I will send a request. In fact it is not the first time this was done, then we had exactly the situation with only a -venv package and nothing in the `octroprint` namespace. Someone noticed that there is no "normal" package and created it again, but could not get it to work reliably. After disowning and two maintainer switches it was adopted by the current maintainer and he added the venv there too... that is how we ended up with that misnamed duplicate.
I'm going to reject the request to delete the other package mostly to open up the way to a merge as suggested above.
btw: The open orphan request should be rejected too, it was updated and does not matter anyway after a merge.
Regards, Caleb
participants (3)
-
Caleb Maclennan
-
Jake
-
notify＠aur.archlinux.org