Hello, On August 29, 2025 12:34:36 PM PDT, Tianyu Chen <[email protected]> wrote: >Dear Helmut and nvchecker maintainer, > >On Mon, 21 Apr 2025 09:29:59 +0200 Helmut Grohne wrote: > >> Package: python3-nvchecker >> Version: 2.12-2 >> Severity: important >> Control: affects -1 + nvchecker >> X-Debbugs-C: [email protected], [email protected] >> >> Hi, >> >> I spent a deeper look at these two packages after reporting the >> undeclared file conflicts earlier and observe more problems here. >> >> It seems to me that src:nvchecker originally packaged this and later >> src:python-nvchecker duplicated it. In theory, we should have removed >> the duplicate and rescued the existing package. Instead, both got >> maintained concurrently. Eventually I reported the file conflict and >> that resulted in python3-nvchecker to declare Breaks+Replaces+Provides >> nvchecker. This effectively is a package takeover. Is it coordinated in >> any way? Is it authorized by the present src:nvchecker maintainers? >>
I was not aware of that---nvchecker itself is under lowNMU so as to not deter others from helping and I don't mind handing over official maintainership of the package. I myself lost steam on it due to multiple other packages that needed to be fixed (at the time) to get the autopkgtests to work nicely. >> Now given that src:nvchecker has received its last maintainer upload in >> 2021 and lacked behind upstream by several versions, we can certainly >> say it wasn't in its best shape. From a wider perspective, handing over >> maintenance to a more active maintainer can be beneficial. At this >> point, it would most probably make sense to simply remove src:nvchecker >> from unstable after figuring out what good aspects (e.g. an example >> file) can be rescued into src:python-nvchecker. >> >> Last but not least, Provides is not a proper package transition. apt >> will not move an existing installation of nvchecker over to >> python3-nvchecker by itself. src:nvchecker should temporarily include a >> real, transitional nvchecker binary package to finish the transition. >> Introducing a new binary package requires a freeze exception, but this >> seems like one of those cases where I expect it to be granted. > >As src:nvchecker is not in bullseye, bookworm, nor trixie, and >src:python-nvchecker is in trixie, I intend to maintain binary package >nvchecker in src:python-nvchecker, under Debian Python Team's umbrella. > >I plan to add a transitional nvchecker binary package in src:python-nvchecker, >to allow a smooth transition. > >Currently, I've done the changes in: > >https://salsa.debian.org/python-team/packages/python-nvchecker > >As moving the nvchecker binary package to src:python-nvchecker will cause the >removal of src:nvchecker, I consider delaying the upload a bit would be better >to get your thoughts. > >I plan to upload this after 21 days. If you consider the changes >inappropriate, let me know your thoughts, and I will hold the upload. > The proper package name for an executable program should not be python-*, so I don't think the nvchecker name should be in a transitional role. You can have python-nvchecker for the python module, but it's not helpful for users to have to be aware of the implementation language if they just want to use the cli. So I personally think the duplicate package should fold into src:nvchecker and that nvchecker should remain the primary binary package name. I don't think that the source package presence in a release has a special bearing since what matters there are the binary packages. thanks and regards Afif
