[pacman-dev] Discussion on changelogs
Hi list The subject came up at FOSDEM on a packaging discussion. I thought it'd be worth bringing up here. Pacman has extremely basic and non-advertised support for changelogs. These are maintainer changelogs, not upstream changelogs, and seem to be completely useless. In fact, in my 900~ package install, only iotop and zsh-syntax-highlighting have a changelog at all and they all list "Updated to release ...". My personal recommendation, and what makes the most sense, is to allow for (and highly recommend) upstream changelogs. If there is a changelog file, that can be displayed in pacman -Qc (regardless of its format). There is also the subject of online-only changelogs. Should they be downloaded, or should -Qc display "Read the changelog at http://..."? My first thought is that's up to the packager/maintainer, they would know better on a per-package basis. Debian is really good with its packaging changelogs. Afaik they're the only distro that properly uses them. They're a lot less relevant to arch linux due to the very nature of the distro ("trust upstream") but I don't think they're useless; in fact, we should probably distinguish packaging and upstream changelogs. Final question is, what of the syntax? I have a few things in mind but I'd like to hear whether such changes would be welcome at all first. Cheers J. Leclanche
On Fri, Feb 7, 2014 at 9:39 AM, Jerome Leclanche <adys.wh@gmail.com> wrote:
Hi list
The subject came up at FOSDEM on a packaging discussion. I thought it'd be worth bringing up here. Pacman has extremely basic and non-advertised support for changelogs. These are maintainer changelogs, not upstream changelogs, and seem to be completely useless. In fact, in my 900~ package install, only iotop and zsh-syntax-highlighting have a changelog at all and they all list "Updated to release ...".
Many packages that ship them, don't have an up to date changelog e.g. https://projects.archlinux.org/svntogit/community.git/plain/trunk/ChangeLog?... The consensus is (or at least was half a year ago) that such changelogs should be removed https://bugs.archlinux.org/task/37105
My personal recommendation, and what makes the most sense, is to allow for (and highly recommend) upstream changelogs. If there is a changelog file, that can be displayed in pacman -Qc (regardless of its format). There is also the subject of online-only changelogs. Should they be downloaded, or should -Qc display "Read the changelog at http://..."? My first thought is that's up to the packager/maintainer, they would know better on a per-package basis.
There's https://bugs.archlinux.org/task/33960
Debian is really good with its packaging changelogs. Afaik they're the only distro that properly uses them. They're a lot less relevant to arch linux due to the very nature of the distro ("trust upstream") but I don't think they're useless; in fact, we should probably distinguish packaging and upstream changelogs. Final question is, what of the syntax? I have a few things in mind but I'd like to hear whether such changes would be welcome at all first.
Cheers
J. Leclanche
If upstream changelogs become supported, I have a patch for makepkg to allow a changelog() function in PKGBUILD to generate the changelog at packaging time (from VCS messages, for instance). Let me know if it becomes relevant, or if a task comes up where I can post it. /Emil On Fri, Feb 7, 2014 at 6:59 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Fri, Feb 7, 2014 at 9:39 AM, Jerome Leclanche <adys.wh@gmail.com> wrote:
Hi list
The subject came up at FOSDEM on a packaging discussion. I thought it'd be worth bringing up here. Pacman has extremely basic and non-advertised support for changelogs. These are maintainer changelogs, not upstream changelogs, and seem to be completely useless. In fact, in my 900~ package install, only iotop and zsh-syntax-highlighting have a changelog at all and they all list "Updated to release ...".
Many packages that ship them, don't have an up to date changelog e.g. https://projects.archlinux.org/svntogit/community.git/plain/trunk/ChangeLog?... The consensus is (or at least was half a year ago) that such changelogs should be removed https://bugs.archlinux.org/task/37105
My personal recommendation, and what makes the most sense, is to allow for (and highly recommend) upstream changelogs. If there is a changelog file, that can be displayed in pacman -Qc (regardless of its format). There is also the subject of online-only changelogs. Should they be downloaded, or should -Qc display "Read the changelog at http://..."? My first thought is that's up to the packager/maintainer, they would know better on a per-package basis.
There's https://bugs.archlinux.org/task/33960
Debian is really good with its packaging changelogs. Afaik they're the only distro that properly uses them. They're a lot less relevant to arch linux due to the very nature of the distro ("trust upstream") but I don't think they're useless; in fact, we should probably distinguish packaging and upstream changelogs. Final question is, what of the syntax? I have a few things in mind but I'd like to hear whether such changes would be welcome at all first.
Cheers
J. Leclanche
On 07/02/14 18:39, Jerome Leclanche wrote:
Hi list
The subject came up at FOSDEM on a packaging discussion. I thought it'd be worth bringing up here. Pacman has extremely basic and non-advertised support for changelogs. These are maintainer changelogs, not upstream changelogs, and seem to be completely useless. In fact, in my 900~ package install, only iotop and zsh-syntax-highlighting have a changelog at all and they all list "Updated to release ...".
Pacman also has "unadvertised" delta support. No need to remove it because it is not used...
My personal recommendation, and what makes the most sense, is to allow for (and highly recommend) upstream changelogs. If there is a changelog file, that can be displayed in pacman -Qc (regardless of its format). There is also the subject of online-only changelogs. Should they be downloaded, or should -Qc display "Read the changelog at http://..."? My first thought is that's up to the packager/maintainer, they would know better on a per-package basis.
I'll just point out as an Arch dev and not a pacman one, that Arch will probably never include a ChangeLog in their packages. Extra maintenance burden like this is generally seen as unnecessary.
Debian is really good with its packaging changelogs. Afaik they're the only distro that properly uses them. They're a lot less relevant to arch linux due to the very nature of the distro ("trust upstream") but I don't think they're useless; in fact, we should probably distinguish packaging and upstream changelogs.
Looking at Debian. They supply a packaging changelog exactly like what is available in pacman (viewed by dch -v version-revision or dch -i). So the advantage there is that they can just display the appropriate part of the ChangeLog file. I guess that requires the file format to be quite strict. Debian also puts that upstream ChangeLog/NEWS etc in /usr/share/doc/package. Again, this is nothing that can not be done in makepkg already, and is a distribution policy matter. Lets look at rpm. rpm -q --changelog <pkg> displays the packaging changelog. I'm not sure that they have an option to display the changes in a given version only. Including upstream changelogs is a distributional decision. In conclusion, we have the same support for ChangeLog that every other package manager has. And I am convinced that the changelog for the package is the changelog a package manager should display. Whether to include a packaging changelog at all and what format it is in is a distribution decision. Whether to also include an upstream development changelog in the package is also a distributional decision. I see nothing that needs changed in makepkg/pacman. Allan
On Sun, Feb 9, 2014 at 1:02 AM, Allan McRae <allan@archlinux.org> wrote:
In conclusion, we have the same support for ChangeLog that every other package manager has. And I am convinced that the changelog for the package is the changelog a package manager should display.
Whether to include a packaging changelog at all and what format it is in is a distribution decision. Whether to also include an upstream development changelog in the package is also a distributional decision.
I see nothing that needs changed in makepkg/pacman.
Yeah - I wasn't arguing the current changelog feature needed to be removed. I was however arguing that we may want to be able to include upstream changelogs as well in the package. It's fair if arch devs don't do it for whatever reason, but usually it's just a matter of adding a single line to the PKGBUILD, once so it's a perfectly scalable burden, so to say. Packaging changelogs however are a massive maintenance burden as they need to be updated every release. So currently, pacman supports a feature nobody uses, and doesn't support a "fire and forget" feature that applies to thousands of packages. J. Leclanche
On 09/02/14 19:54, Jerome Leclanche wrote:
On Sun, Feb 9, 2014 at 1:02 AM, Allan McRae <allan@archlinux.org> wrote:
In conclusion, we have the same support for ChangeLog that every other package manager has. And I am convinced that the changelog for the package is the changelog a package manager should display.
Whether to include a packaging changelog at all and what format it is in is a distribution decision. Whether to also include an upstream development changelog in the package is also a distributional decision.
I see nothing that needs changed in makepkg/pacman.
Yeah - I wasn't arguing the current changelog feature needed to be removed. I was however arguing that we may want to be able to include upstream changelogs as well in the package. It's fair if arch devs don't do it for whatever reason, but usually it's just a matter of adding a single line to the PKGBUILD, once so it's a perfectly scalable burden, so to say. Packaging changelogs however are a massive maintenance burden as they need to be updated every release. So currently, pacman supports a feature nobody uses, and doesn't support a "fire and forget" feature that applies to thousands of packages.
Sure it does. Taking the Debian approach: install -Dm644 ChangeLog $pkgdir/usr/share/doc/$pkgname/ChangeLog Allan
On Sun, Feb 9, 2014 at 10:06 AM, Allan McRae <allan@archlinux.org> wrote:
Sure it does. Taking the Debian approach:
install -Dm644 ChangeLog $pkgdir/usr/share/doc/$pkgname/ChangeLog
In that case, we need to "officialise" it in the wiki imo. I'm still strongly in favour of adding a keyword/function to PKGBUILD. I believe in declarativeness... that's a word, right? J. Leclanche
On 09/02/14 20:19, Jerome Leclanche wrote:
On Sun, Feb 9, 2014 at 10:06 AM, Allan McRae <allan@archlinux.org> wrote:
Sure it does. Taking the Debian approach:
install -Dm644 ChangeLog $pkgdir/usr/share/doc/$pkgname/ChangeLog
In that case, we need to "officialise" it in the wiki imo. I'm still strongly in favour of adding a keyword/function to PKGBUILD. I believe in declarativeness... that's a word, right?
Pacman does not have a wiki... so I guess you are talking about Arch policy, in which case I believe the answer would be no. If upstream wanted their ChangeLog installed to your system, they would do that on "make install". Allan
On Sun, Feb 9, 2014 at 10:27 AM, Allan McRae <allan@archlinux.org> wrote:
Pacman does not have a wiki... so I guess you are talking about Arch policy, in which case I believe the answer would be no. If upstream wanted their ChangeLog installed to your system, they would do that on "make install".
So... we're back to what I was saying a couple of emails ago. *shrugs* But yes, I was talking about Arch in that instance. Can you explain why you are against the ability to add upstream changelogs to the PKGBUILD (in a declarative way, that is)? J. Leclanche
On 09/02/14 20:37, Jerome Leclanche wrote:
On Sun, Feb 9, 2014 at 10:27 AM, Allan McRae <allan@archlinux.org> wrote:
Pacman does not have a wiki... so I guess you are talking about Arch policy, in which case I believe the answer would be no. If upstream wanted their ChangeLog installed to your system, they would do that on "make install".
So... we're back to what I was saying a couple of emails ago. *shrugs* But yes, I was talking about Arch in that instance. Can you explain why you are against the ability to add upstream changelogs to the PKGBUILD (in a declarative way, that is)?
It is not the package managers job to maintain information about upstream development. The job for a package manager is to maintain information about the actual package file. Hence the only changelog that is appropriate is the changelog of the packaging process. A
On Sun, Feb 9, 2014 at 10:46 AM, Allan McRae <allan@archlinux.org> wrote:
It is not the package managers job to maintain information about upstream development. The job for a package manager is to maintain information about the actual package file. Hence the only changelog that is appropriate is the changelog of the packaging process.
Alright, that's a fair point. I'm still in favour of this but I see what you're saying. J. Leclanche
participants (4)
-
Allan McRae
-
Emil Lundberg
-
Jerome Leclanche
-
Karol Blazewicz