RfC: Maintain separate "package maintainers NEWS" file for each release?

As lesson learned from our current rollout of v1.3.3 I suggest to maintain a separate "Package Maintainer NEWS" file which shall contain pkg maintainer relevant changes like - changed dependencies - installation path changes - unexpected file and folder renamings etc. Any opinions (also on the best file name for this)? Optionally we could maintain a list of known BiT packages incl. a link to the pkg maintainer web sites in our wiki or FAQ to direct users with packaging-related issues to the according responsible pkg. maintainer. I have asked for community support to compile such a list in one of our issues: https://github.com/bit-team/backintime/issues/1401#issuecomment-1412915694

@buhtz wrote her: https://github.com/bit-team/backintime/issues/1401#issuecomment-1413244974
We do have a changelog. IMHO no need for redundancy. A good/motivated distro maintainer take care of such a file.
Yes, our changelog would work (if I hadn't forgotten to capture the newly discovered dependencies there BEFORE the release :-( BTW: There is still open work for me to document the weak dependencies (mainly on required cmd line tools)...
if the repo is setup correctly fitting to the python packaging standards (e.g. using a pyproject.toml) all dependencies are "coded" in there.
That sounds very promissing, I have never tried this before! I think we need to get a clear picture if and how pyproject.toml - maintains python-external dependencies (like eg. themes and icons or required cmd line tools like rsync) in a distro-independent (!) way (different pkg names), e.g.: Ubuntu: oxygen-icon-theme Arch: oxygen-icons If the answer above question is YES: Could we end up then in doing the pkg maintenance half-way ourselves then (instead of letting downstreams do the work)? Also: My current understanding is (by flying over the PEP-specs for this) that pyproject.TOML is mainly meant for metadata and *build* dependencies while I have not directly seen a way to separately specify the *installation* dependencies (but I have not fully read the PEP-specs so far). On Thu, 2023-02-02 at 01:04 +0100, BiT dev wrote:

Am 02.02.2023 11:50 schrieb BiT dev:
Yes, our changelog would work (if I hadn't forgotten to capture the newly discovered dependencies there BEFORE the release :-(
That isn't a big deal. ;) The workflow is something we need to train and we will become warm with. When we would have a second changelog then we will have two documents we need to maintain and with redundant information we need to kept sync.
I think we need to get a clear picture if and how pyproject.toml
Upcoming... This moves the entry up on my todo list. ;)
You bring up some good question. I will do more research about it. I would answer partial YES. But keep in mind it is not our responsibility (as upstream) to take care of package names in distros. This is up to the distro maintainers. And I assume they have tools to handle that. For example when I need "pyfakefs" as a dependency a Debian maintainer today should be able to translate that into "python-pyfakefs" debian-package name. I'm not sure how they handle that but we don't have to care. But I will ask just for our knowledge. For external dependencies not related to Python I'm currently not aware of a pyproject-toml-related solution. I also doubt that the Python build system is related to that task. But I'll check out and suspect that we are not the first ones with that "problem". Maybe there is something like a MANIFEST or requirements file standard.
It is also independent from the build tools where are several exists in the python universe. See this real world example https://codeberg.org/buhtz/buhtzology/src/branch/develop/pyproject.toml Beginning on line 32 with "dependencies = [" you find 6 packages that could be named "install dependencies". They are installed/checked by default when you do python3 -m pip install buhtzology When you also want to make unittests and all the other stuff that is related to developers, contributors and maintainers you have to explicit specify this. python3 -m pip install buhtzology[dev] You see the "[dev]"? This an optional dependency named by myself and specified in line 41 in pyproject.toml. You can have as much as you like. Example here in section "Dependencies": https://godatadriven.com/blog/a-practical-guide-to-setuptools-and-pyproject-... As a short preview to my pyproject-toml-for-BIT-approach. The fact that we have two "components" (GUI and CLI) make it complex. My first approach works but is not a good solution from the viewpoint of distro maintainers. So I will implement another one. We can discuss this then in details later. I'll report back. Christian

@buhtz wrote her: https://github.com/bit-team/backintime/issues/1401#issuecomment-1413244974
We do have a changelog. IMHO no need for redundancy. A good/motivated distro maintainer take care of such a file.
Yes, our changelog would work (if I hadn't forgotten to capture the newly discovered dependencies there BEFORE the release :-( BTW: There is still open work for me to document the weak dependencies (mainly on required cmd line tools)...
if the repo is setup correctly fitting to the python packaging standards (e.g. using a pyproject.toml) all dependencies are "coded" in there.
That sounds very promissing, I have never tried this before! I think we need to get a clear picture if and how pyproject.toml - maintains python-external dependencies (like eg. themes and icons or required cmd line tools like rsync) in a distro-independent (!) way (different pkg names), e.g.: Ubuntu: oxygen-icon-theme Arch: oxygen-icons If the answer above question is YES: Could we end up then in doing the pkg maintenance half-way ourselves then (instead of letting downstreams do the work)? Also: My current understanding is (by flying over the PEP-specs for this) that pyproject.TOML is mainly meant for metadata and *build* dependencies while I have not directly seen a way to separately specify the *installation* dependencies (but I have not fully read the PEP-specs so far). On Thu, 2023-02-02 at 01:04 +0100, BiT dev wrote:

Am 02.02.2023 11:50 schrieb BiT dev:
Yes, our changelog would work (if I hadn't forgotten to capture the newly discovered dependencies there BEFORE the release :-(
That isn't a big deal. ;) The workflow is something we need to train and we will become warm with. When we would have a second changelog then we will have two documents we need to maintain and with redundant information we need to kept sync.
I think we need to get a clear picture if and how pyproject.toml
Upcoming... This moves the entry up on my todo list. ;)
You bring up some good question. I will do more research about it. I would answer partial YES. But keep in mind it is not our responsibility (as upstream) to take care of package names in distros. This is up to the distro maintainers. And I assume they have tools to handle that. For example when I need "pyfakefs" as a dependency a Debian maintainer today should be able to translate that into "python-pyfakefs" debian-package name. I'm not sure how they handle that but we don't have to care. But I will ask just for our knowledge. For external dependencies not related to Python I'm currently not aware of a pyproject-toml-related solution. I also doubt that the Python build system is related to that task. But I'll check out and suspect that we are not the first ones with that "problem". Maybe there is something like a MANIFEST or requirements file standard.
It is also independent from the build tools where are several exists in the python universe. See this real world example https://codeberg.org/buhtz/buhtzology/src/branch/develop/pyproject.toml Beginning on line 32 with "dependencies = [" you find 6 packages that could be named "install dependencies". They are installed/checked by default when you do python3 -m pip install buhtzology When you also want to make unittests and all the other stuff that is related to developers, contributors and maintainers you have to explicit specify this. python3 -m pip install buhtzology[dev] You see the "[dev]"? This an optional dependency named by myself and specified in line 41 in pyproject.toml. You can have as much as you like. Example here in section "Dependencies": https://godatadriven.com/blog/a-practical-guide-to-setuptools-and-pyproject-... As a short preview to my pyproject-toml-for-BIT-approach. The fact that we have two "components" (GUI and CLI) make it complex. My first approach works but is not a good solution from the viewpoint of distro maintainers. So I will implement another one. We can discuss this then in details later. I'll report back. Christian
participants (2)
-
BiT dev
-
c.buhtz@posteo.jp