On Mon, Oct 07, 2024 at 02:15:54AM -0700, Ralph Lange wrote: > Yes, I know your name from Tech-Talk... > I'd be happy to work with you as a co-maintainer for procServ!
I'm glad to hear that! > All your findings are correct. > I never had the intention to drop procServ packaging, but interest from the > EPICS collaboration in system packaging has sharply dropped and ITER (which > I'm working for since 10 years) is not using procServ nor Debian. > A few sessions/workshops at EPICS Collaboration Meetings over the last > years showed dwindling support for system packaging. Everyone is moving to > containers or using distro-independent packaging (e.g., Conda). That's interesting. At LNLS, we are also moving to containers. Still, we use Debian containers with procServ [1]. At beamlines, this is allowing us to migrate from NFS-based to containerized IOCs while keeping the same interface accessing the IOC shell. Such interface is expected by an in-house script which handles IOC starting, stopping, accessing the shell, and so on. BTW, starting to run them in containers under procServ is one of the reasons we noticed the latest version wasn't available in Debian. That's because `--oneshot` is really handy for service-like execution, both under systemd and containers. [1] https://github.com/cnpem/epics-in-docker/blob/v0.11.0/Dockerfile#L20 > My blocker question for a new package version was (in 2019 and still is): > What should be done about the Python systemd helper scripts that were > contributed? > I have zero experience in Python packaging and have never received any > community feedback about those scripts. > Packaging something that I don't know if it works and I don't know how to > package doesn't sound right. I've also been questioning myself this. We don't use those scripts at LNLS for generating systemd units, as we already have a (legacy) in-house script for handling IOCs. To be honest, I think we actually never tried them. Although I think Python packaging shouldn't be a big concern, I share your feeling that packaging them without knowing if it is properly working doesn't seem right. One approach that could work is not to package them at first, and wait until someone complains about it. This way, we at least know it pays off to put effort in it. Hopefully, it would also mean users finding and reporting bugs. What's your opinion on that? > Looking at your MR, I see that you didn't package those scripts. Fair > enough. Have you considered adding them to packaging? That MR fixes up mostly Debian-related issues with version 2.7.0-1. Once merged and uploaded, it will give us a procserv 2.7.0-2 following latest Debian standards. This should fix a pending dependency bug [2] and other metadata-related problems that make Debian Tracker [3] and Lintian [4] a bit sad. As far as I could see, those Python scripts come from 2.8.0 onwards. Thus, I actually didn't have to give an answer to your question in that MR. My next move will be to upgrade to the latest version, that's when we'll have to answer it. [2] https://bugs.debian.org/1016857 [3] https://tracker.debian.org/procserv [4] https://udd.debian.org/lintian/?packages=procserv > The PGP fingerprint that you found > C495 0D86 9EC0 5EA3 F4AB 743B 9CDF 4AF4 569D D158 > is correct and refers to the PGP key I am using upstream and with Debian > packaging. (Also signing this mail as verification.) Thank you very much. I'll move forward on adding signature verification. > Moving the repo to the Debian namespace is certainly fine with me as it > will indeed make things easier. > Its current location is where it ended up after the move from Alioth. I > didn't actively do anything about the location. I had imagined that was the case. Thanks for the thumbs up on that. > Please add yourself to the uploaders. > Even as I can't promise to spend more time on packaging pro-actively, I'm > happy to review and contribute to your efforts. Having your reviews will be very welcome. Thank you for maintaining it upstream, and also in Debian. Best regards, Henrique F. Simoes
