On Sun, Aug 31, 2025 at 12:25:34AM -0700, Afif Elghraoui wrote: > 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.
Thank you for your thoughts! I've moved the executables to binary:nvchecker. Can you have a look here? https://salsa.debian.org/python-team/packages/python-nvchecker/-/commit/56de527 https://salsa.debian.org/python-team/packages/python-nvchecker/-/commit/05d4ab6 Best regards, Tianyu Chen
