[arch-general] changelogs (was Re: postgresql 9.3 -> 9.4)
The thread about the postgresql update reminded me of one of the few things about Ubuntu that I miss: package updates usually included a useful changelog entry describing what was fixed and/or new. Perhaps I assume too much, but I imagine Arch package maintainers would generally be aware of the changes in an update they're making, and so it wouldn't be much additional work to include that information in a changelog entry. When I first started using Arch I'd hoped "pacman -Qc" would do this, but at this point only three of the 867 packages on my system have a changelog, and most of those entries are just "version bump" or equivalent. Carl
On Thu, 29 Jan 2015 at 16:08:02, Carl Schaefer wrote:
The thread about the postgresql update reminded me of one of the few things about Ubuntu that I miss: package updates usually included a useful changelog entry describing what was fixed and/or new. Perhaps I assume too much, but I imagine Arch package maintainers would generally be aware of the changes in an update they're making, and so it wouldn't be much additional work to include that information in a changelog entry.
It actually *is* much additional work. Bumping the package version usually takes ~5 seconds. That does not include the time to build and test the package but we don't need to watch the build process and packages are often tested by using them in production. So, compared to those five seconds, looking up every single change and coming up with a change log is a lot of time -- and it usually doesn't pay off, apart from corner cases. Please examine the mailing lists, this story has been discussed several times already. Keeping bureaucracy to a minimum is one of the reasons we can provide updates much faster than other distributions. While I agree that warnings and front page news should be given where appropriate, I cannot comment on PostgreSQL, which I don't use. As it seems to be a similar process on every major update and there even seems to be a script to warn you, I don't see any need for another notice, though. As a database administrator, you should be aware of what happens when you update the DBMS. Maybe some post-upgrade message would be helpful...
When I first started using Arch I'd hoped "pacman -Qc" would do this, but at this point only three of the 867 packages on my system have a changelog, and most of those entries are just "version bump" or equivalent. Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.01.2015 16:33, Lukas Fleischer wrote:
On Thu, 29 Jan 2015 at 16:08:02, Carl Schaefer wrote:
The thread about the postgresql update reminded me of one of the few things about Ubuntu that I miss: package updates usually included a useful changelog entry describing what was fixed and/or new. Perhaps I assume too much, but I imagine Arch package maintainers would generally be aware of the changes in an update they're making, and so it wouldn't be much additional work to include that information in a changelog entry.
It actually *is* much additional work. Bumping the package version usually takes ~5 seconds. That does not include the time to build and test the package but we don't need to watch the build process and packages are often tested by using them in production. So, compared to those five seconds, looking up every single change and coming up with a change log is a lot of time -- and it usually doesn't pay off, apart from corner cases. Please examine the mailing lists, this story has been discussed several times already. Keeping bureaucracy to a minimum is one of the reasons we can provide updates much faster than other distributions.
I understand the effort the packaging requires. Writing changelogs may be to much work and this is not what I propose. On the other hand, upgrades that break stuff are seldom. As is the case for postgresql. This happens every few month or so. On 29.01.2015 14:22, Bardur Arantsson wrote:
If the problem here is that it would be a chore to do this for maintainers for every X.Y -> X.(Y+1) upgrade, then maybe Arch package descriptions could grow a field or flag to handle such things semi-automatically? Maybe something as simple as "if the version number is about to change in *this way*, then warn loudly using *this message*".
Wouldn't that be a sensible way? The increased overhead for the maintainer would be to tick a flag in addition to the version bump. In the case of postgresql this would be a as simple as if (oldMajor < newMajor || ((oldMajor == newMajor) && (oldMinor < newMinor)) { printUpgradeWarning(); } Of course the condition would have to be serialized in the package meta-data some way. I have only very limited knowledge on the pacman internals. Maybe someone can come up with an estimate how big the effort would be to implement this.
While I agree that warnings and front page news should be given where appropriate, I cannot comment on PostgreSQL, which I don't use. As it seems to be a similar process on every major update and there even seems to be a script to warn you, I don't see any need for another notice, though. As a database administrator, you should be aware of what happens when you update the DBMS. Maybe some post-upgrade message would be helpful...
Agreed -- it's just that I am not a DBMS admin in this case. This was on my personal computer where I can hardly spent the time to look up every package version change. In times where remotely exploitable security flaws turn up almost daily, this is just not acceptable. So, I have to trust the packaging system to some degree. Of course one should check Arch announcements on the website and maybe follow the mailing lists. There wasn't any notice for postgresql in this case. Regards, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUylqNAAoJELvxnEIeMg5luLUH/0gTG37RjJNpV6XTFqesVUqH ASNywi0VRQ0SSQAV4FFv/BymNMet9OVBBsxCOQooucGt6kakferujJMtRM4qkDtM eGJK1ZJ1gtgNU415rZTWN/wCOby3J3r/HCL0NfTfXjmYJ2Q53WmcsCtGCSyQIJxR jcggzK52kuTPYobeS7c2FoQguIS0CIdEJqUDcgF/PcxjXe/a9t6is4m+CeejJnXI J5U8yqgaB9/4/wtiHMaGP9LCGQFW6582pIUwGd4ozId6Rr9ZJhcDDHrGaxtTu9oG zWzG68hvhQKZUi2leNIhDh9k3tG8dOzyTt+kaM3IZkgiAwRG373cVGG+2IWti38= =OqYb -----END PGP SIGNATURE-----
On Thu, 29 Jan 2015 at 17:06:43, Georg Altmann wrote:
[...] On 29.01.2015 14:22, Bardur Arantsson wrote:
If the problem here is that it would be a chore to do this for maintainers for every X.Y -> X.(Y+1) upgrade, then maybe Arch package descriptions could grow a field or flag to handle such things semi-automatically? Maybe something as simple as "if the version number is about to change in *this way*, then warn loudly using *this message*".
Wouldn't that be a sensible way? The increased overhead for the maintainer would be to tick a flag in addition to the version bump. In the case of postgresql this would be a as simple as
if (oldMajor < newMajor || ((oldMajor == newMajor) && (oldMinor < newMinor)) { printUpgradeWarning(); }
Of course the condition would have to be serialized in the package meta-data some way. I have only very limited knowledge on the pacman internals. Maybe someone can come up with an estimate how big the effort would be to implement this. [...]
It isn't that easy. You cannot simply tick a flag, you need to maintain a variable that keeps track of the last version that caused a warning. Otherwise, there's no way to warn a user who upgrades straight from 1.0.0 to 2.1.0 when there were intermediate releases 1.1.0 and 2.0.0 and some change between 1.1.0 and 2.0.0 that is worth a warning. And as a matter of fact, that is what we already do in a lot of packages. You can have a look at the install scriptlets of btrfs-progs, cups, dhcp, dmraid, dovecot, ebtables, intel-ucode, linux, lirc, lvm2, mariadb, nginx, openvpn, systemd, varnish, just to get an idea of what it looks like. As I mentioned before, adding a similar check to PostgreSQL might be a good idea but I, as a non-PostgreSQL user, cannot judge whether that works and is worthwhile.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.01.2015 17:44, Lukas Fleischer wrote:
On Thu, 29 Jan 2015 at 17:06:43, Georg Altmann wrote:
[...] On 29.01.2015 14:22, Bardur Arantsson wrote:
If the problem here is that it would be a chore to do this for maintainers for every X.Y -> X.(Y+1) upgrade, then maybe Arch package descriptions could grow a field or flag to handle such things semi-automatically? Maybe something as simple as "if the version number is about to change in *this way*, then warn loudly using *this message*".
Wouldn't that be a sensible way? The increased overhead for the maintainer would be to tick a flag in addition to the version bump. In the case of postgresql this would be a as simple as
if (oldMajor < newMajor || ((oldMajor == newMajor) && (oldMinor < newMinor)) { printUpgradeWarning(); }
Of course the condition would have to be serialized in the package meta-data some way. I have only very limited knowledge on the pacman internals. Maybe someone can come up with an estimate how big the effort would be to implement this. [...]
It isn't that easy. You cannot simply tick a flag, you need to maintain a variable that keeps track of the last version that caused a warning. Otherwise, there's no way to warn a user who upgrades straight from 1.0.0 to 2.1.0 when there were intermediate releases 1.1.0 and 2.0.0 and some change between 1.1.0 and 2.0.0 that is worth a warning. And as a matter of fact, that is what we already do in a lot of packages. You can have a look at the install scriptlets of btrfs-progs, cups, dhcp, dmraid, dovecot, ebtables, intel-ucode, linux, lirc, lvm2, mariadb, nginx, openvpn, systemd, varnish, just to get an idea of what it looks like. As I mentioned before, adding a similar check to PostgreSQL might be a good idea but I, as a non-PostgreSQL user, cannot judge whether that works and is worthwhile.
For postgresql it is exactly that easy. A comparison of the version numbers is enough: If they differ at least a minor version, churn out the warning. Implementing it this way, the overhead for the maintainer would be zero. But thanks for clarifying. I will look into the scriptlets for the packages you mentioned. And I will try to make a bug report based on that for postgresql. Regards, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUynXYAAoJELvxnEIeMg5lrWYH+QHdJbx+wuLv5KcaLWeM0ZVO +lzehIt3Z+XvyJQQrtX/BXUEzq3rUNC4nnswKWqOZv/zyzoAfZchF+cIi75k7/Mt W5ZWPpnU/gmQCRifHI+wHSF19aa+0hvFtR7CGdEkO4nnPtmveyibNDxtDaD0Jy8B kZrSZ5gXsVFqIoGUZivq4eXDTHDXljui60SFzD76BCc1zywWpWJlbUG4ZjSCt8bP DRtlfEQzC/XQrZhoaGJceM+MT0Xp/GhoPITUtkeAuN/VF/hUbJOtuoKAs1vcq63U Ps4vLaqCMk8vQm5UFnzBXSAFR91nb8CceuYfKtaHGNy3P8UF2g2Be7C4ruLhMlE= =mvrh -----END PGP SIGNATURE-----
participants (3)
-
Carl Schaefer
-
Georg Altmann
-
Lukas Fleischer