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/packages/octoprint-venv/
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
