[pacman-dev] Fix srcinfo sometimes printing double newline at the end

Message ID CACbE=3pkfRrx7QT4nTNqDtNMif+p2Bpoj1NcqUKvX7MFJhTqMQ@mail.gmail.com
State New
Headers show
Series
  • [pacman-dev] Fix srcinfo sometimes printing double newline at the end
Related show

Commit Message

Martin Rys June 25, 2020, 11:09 p.m. UTC
Hi,
this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually
generates a file with two newlines at the end.

This logic happens in pacman/scripts/libmakepkg/srcinfo.sh.in
(/usr/share/makepkg/srcinfo.sh)

The relevant functions:

srcinfo_close_section() {
echo
}

srcinfo_write_global() {
...
srcinfo_open_section 'pkgbase' "${pkgbase:-$pkgname}"
srcinfo_write_section_details ''
srcinfo_close_section
}

srcinfo_write_package() {
...
srcinfo_open_section 'pkgname' "$1"
srcinfo_write_section_details "$1"
srcinfo_close_section
}

As you can see, the functions process section details, and then print
out a newline no matter if details printed something or not.

The write_section_details eventually leads to:

srcinfo_write_attr() {
...
printf "\t$attrname = %s\n" "${attrvalues[@]}"
}

Which seems to always print out a newline, so I believe the
srcinfo_close_section function is not needed there and simply
removing it and the two lines that call it would solve this issue, as
per the patchfile in the attachment.

Thanks for taking a look at this,
Marti

Comments

Denton Liu June 25, 2020, 11:27 p.m. UTC | #1
Hi Marti,

On Fri, Jun 26, 2020 at 01:09:54AM +0200, Martin Rys wrote:
> Hi,
> this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually
> generates a file with two newlines at the end.

I agree with you, this bugs me a lot too.

[...]

> Which seems to always print out a newline, so I believe the
> srcinfo_close_section function is not needed there and simply
> removing it and the two lines that call it would solve this issue, as
> per the patchfile in the attachment.

I proposed a similar patch recently[0] but it was rejected as the
newline separators are apparently part of the spec so they should be
retained[1]. I sent out another patch after that only removes the final
newline but it wasn't reviewed so I thought that the pacman devs thought
it was a non-issue. Since you seem to agree with me, though, I'll resend
that patch and hopefully it'll be reviewed this time around.

Thanks,

Denton

[0]: https://lists.archlinux.org/pipermail/pacman-dev/2020-June/024399.html
[1]: https://lists.archlinux.org/pipermail/pacman-dev/2020-June/024405.html
Allan McRae June 25, 2020, 11:43 p.m. UTC | #2
On 26/6/20 9:27 am, Denton Liu wrote:
> Hi Marti,
> 
> On Fri, Jun 26, 2020 at 01:09:54AM +0200, Martin Rys wrote:
>> Hi,
>> this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually
>> generates a file with two newlines at the end.
> 
> I agree with you, this bugs me a lot too.
> 
> [...]
> 
>> Which seems to always print out a newline, so I believe the
>> srcinfo_close_section function is not needed there and simply
>> removing it and the two lines that call it would solve this issue, as
>> per the patchfile in the attachment.
> 
> I proposed a similar patch recently[0] but it was rejected as the
> newline separators are apparently part of the spec so they should be
> retained[1]. I sent out another patch after that only removes the final
> newline but it wasn't reviewed so I thought that the pacman devs thought
> it was a non-issue. Since you seem to agree with me, though, I'll resend
> that patch and hopefully it'll be reviewed this time around.
> 

Please do not resend patches.  We have a patch tracking system, which
means patches are never lost.

I have given this patch a very low priority. That means with limited
time available to me, I will likely review other patches first.  But it
will get considered at some stage.

Allan
Denton Liu June 25, 2020, 11:51 p.m. UTC | #3
Hi Allan,

On Fri, Jun 26, 2020 at 09:43:39AM +1000, Allan McRae wrote:
> Please do not resend patches.  We have a patch tracking system, which
> means patches are never lost.

Sorry about that, coming from other mailing list projects, I didn't
realise that patches here are automatically tracked. Do you have a link
to the patch tracker?

(Also, if possible, the v2 that I just sent should be used over the old
v2 as it contains an updated commit message without the typo and with a
sign-off.)

> I have given this patch a very low priority. That means with limited
> time available to me, I will likely review other patches first.  But it
> will get considered at some stage.

Thanks!

-Denton
Eli Schwartz June 25, 2020, 11:58 p.m. UTC | #4
On 6/25/20 7:51 PM, Denton Liu wrote:
> Hi Allan,
> 
> On Fri, Jun 26, 2020 at 09:43:39AM +1000, Allan McRae wrote:
>> Please do not resend patches.  We have a patch tracking system, which
>> means patches are never lost.
> 
> Sorry about that, coming from other mailing list projects, I didn't
> realise that patches here are automatically tracked. Do you have a link
> to the patch tracker?

https://patchwork.archlinux.org/project/pacman/list/

> (Also, if possible, the v2 that I just sent should be used over the old
> v2 as it contains an updated commit message without the typo and with a
> sign-off.)

I've marked your v2 patch as superseded. Today's v3 (mislabeled "v2" :p)
is now the current iteration.

>> I have given this patch a very low priority. That means with limited
>> time available to me, I will likely review other patches first.  But it
>> will get considered at some stage.
> 
> Thanks!
> 
> -Denton

At first glance it seems fine to me.

Patch

--- srcinfo.sh.in.edit	2020-06-26 01:02:38.662489244 +0200
+++ srcinfo.sh.in	2020-06-26 01:02:58.086464001 +0200
@@ -30,9 +30,6 @@ 
 	printf '%s = %s\n' "$1" "$2"
 }
 
-srcinfo_close_section() {
-	echo
-}
 
 srcinfo_write_attr() {
 	# $1: attr name
@@ -94,7 +91,6 @@ 
 
 	srcinfo_open_section 'pkgbase' "${pkgbase:-$pkgname}"
 	srcinfo_write_section_details ''
-	srcinfo_close_section
 }
 
 srcinfo_write_package() {
@@ -104,7 +100,6 @@ 
 
 	srcinfo_open_section 'pkgname' "$1"
 	srcinfo_write_section_details "$1"
-	srcinfo_close_section
 }
 
 write_srcinfo_header() {