On Sat, Jul 03, 2021 at 12:50:17PM +0200, David Kalnischkies wrote: >Hi, > >On Wed, Jun 30, 2021 at 06:13:14PM -0500, Brian Thompson wrote: >> * Fix error message being thrown when choosing not to proceed on >> confirmation (closes: #989496). > >If I understand your fix correctly, you have broken the "no" >functionality as the Pre-Install-Pkgs hook has to fail for apt to >actually stop… if they are successful apt will continue with what it was >initially told to do, which seems not inline with what "no" was supposed >to accomplish… could you clarify? I didn't realize that the error message I essentially got rid of was intended functionality. I did some rudimentary testing of the change, and if "no" was selected then any packages with a changelog entry aren't updated, but everything else is. Still, in hindsight, that could break the existing package if dependencies are updated and the source package is held back (that's definitely not what I intended). I should have tested more thoroughly, but I can revert the change. I think the bug that was referenced by that fix shows that [at least] some users were confused by the error message, and didn't realize it was intended functionality. Perhaps cleaning up the error message a bit so users aren't confused by it (which may lead to erroneous bug reports) is a good idea. >(I don't know apt-listchanges code nor do I use the confirmation > functionality of it, so I could easily be entirely wrong) I'm pretty new to it as well. I've only read through the code one time. >(That seems more like we should have a way for the hooks to tell apt to > gracefully wind down, but that doesn't exist so far) That would be ideal. >Could I interest you in joining the apt-team and maintain listchanges as >part of it? I am personally not much help than it comes to python, but >Julian might. Mailing list is deity@lists.debian.org and/or you can join >our IRC channel #debian-apt. I would be interested in joining the apt-team, and I think that makes more sense than making "rogue" contributions outside of the team's view. >I also note that your changelog targets unstable, which might be fine if >you want to fix the mentioned bug and consider it RC (I am not so sure), >but the churn in the package (= reflow of the pt.po and pot file) will >make the release team unhappy. That's good to know. Thanks for pointing that out. This is my first contribution. >Looking at your git history, all this should not be in one single commit >either – individual commits with proper titles and metadata will help >you even: You wrote the changelog by hand, git-buildpackage can do this >for you... > >As a bonus, a week later looking at the history you will still know at >a glance what happened without remembering (or looking up) cryptic >bugreport numbers first – not to mention others. With the data in place >you could then also add a hook to salsa which automatically sets >bugreports to pending after a push of the related commit and many more >fun stuff. > >(It is of course not required, even many upstream projects use "fix #42" > as commit message and are happy and successful. So if that works for > you fine, I am just trying to nudge you to try an alternative which > works better for me, many others and perhaps also you) Also good stuff to know. I will take your advice and follow in others' footsteps. +++ In the meantime, I will take a closer look at the bug reports to see if there are any quick wins there. That way I can proceed with the adoption of the package. Lastly, I'll join the IRC channel and look to join the apt-team, as you suggested. Thanks, David! -- Best regards, Brian T
Attachment:
signature.asc
Description: PGP signature