[aur-dev] .SRCINFO: handling of commits lacking an update and in general

Peter Mattern

26 Jul 2015 26 Jul '15

12:48 p.m.

Hello. Considering the short time AUR 4 is in use the number of commits lacking an update of .SRCINFO seems to be rather high. The resulting problem is a cosmetic one only as the actual PKGBUILD functionality isn't affected but only the package's web page not updated accordingly. Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far. Regards, Peter Mattern

Show replies by date

Remy Marquis

26 Jul 26 Jul

1:03 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Sun, Jul 26, 2015 at 2:48 PM, Peter Mattern wrote:

...

Hello.

Considering the short time AUR 4 is in use the number of commits lacking an update of .SRCINFO seems to be rather high. The resulting problem is a cosmetic one only as the actual PKGBUILD functionality isn't affected but only the package's web page not updated accordingly. Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible.

Rejecting such commits would be welcome, as this issue is unfortunately more serious than being only a cosmetic details. It also affect the RPC interface that can be used by external programs, such as helpers.

...

Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far.

Afaik, the whole point of generating .SRCINFO file on the maintainer machine (rather than the AUR server) is to parse PKGBUILDs accurately without introducing security issues. R.

Doug Newgard

2 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern wrote:

...

Hello.

Considering the short time AUR 4 is in use the number of commits lacking an update of .SRCINFO seems to be rather high. The resulting problem is a cosmetic one only as the actual PKGBUILD functionality isn't affected but only the package's web page not updated accordingly. Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible.

Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO?

...

Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far.

The downside is that running random bash scripts (PKGBUILDs) on the server is an unacceptable security risk. That's the entire reason these metadata files were created. Doug

Peter Mattern

3:09 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

...

On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern wrote:

...
Hello.

Considering the short time AUR 4 is in use the number of commits lacking an update of .SRCINFO seems to be rather high. The resulting problem is a cosmetic one only as the actual PKGBUILD functionality isn't affected but only the package's web page not updated accordingly. Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO? But how should such a change to PKGBUILD look like? IMO each reasonable change to PKGBUILD involves bumping pkgver and/or

Am 26.07.2015 um 16:00 schrieb Doug Newgard: pkgrel and as such makes adjusting .SRCINFO mandatory, no? And even if changes like this do exist I can hardly figure they outweigh the disadvantages stated by Remy in the meantime.

...

...
Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far. The downside is that running random bash scripts (PKGBUILDs) on the server is an unacceptable security risk. That's the entire reason these metadata files were created.

Admittedly I didn't consider PKGBUILD's nature as a shell script when submitting my first post. Given the structure of PKGBUILD I wonder whether writing .SRCINFO at the server side shouldn't be doable in a way avoiding security issues nevertheless. Could of course very well be a task that isn't worth the pain.

Doug Newgard

6:58 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Sun, 26 Jul 2015 17:09:49 +0200 Peter Mattern wrote:

...

...
On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern wrote:

...
Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO? But how should such a change to PKGBUILD look like? IMO each reasonable change to PKGBUILD involves bumping pkgver and/or

Am 26.07.2015 um 16:00 schrieb Doug Newgard: pkgrel and as such makes adjusting .SRCINFO mandatory, no? And even if changes like this do exist I can hardly figure they outweigh the disadvantages stated by Remy in the meantime.

There are plenty of changes that could be made to the PKGBUILD that wouldn't require a change to the .SRCINFO. Anything from formatting changes/cleanups, to restructuring functions, to switching to using install commands instead of cp, to abstracting out variables. You don't want to bump the pkgrel if they don't make any changes to the final package.

...

...
...
Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far. The downside is that running random bash scripts (PKGBUILDs) on the server is an unacceptable security risk. That's the entire reason these metadata files were created.

Admittedly I didn't consider PKGBUILD's nature as a shell script when submitting my first post. Given the structure of PKGBUILD I wonder whether writing .SRCINFO at the server side shouldn't be doable in a way avoiding security issues nevertheless. Could of course very well be a task that isn't worth the pain.

That's what we had before. It only works in very simple cases. Remember, anything that's valid in bash is valid in a PKGBUILD. Doug

Peter Mattern

28 Jul 28 Jul

2:52 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

Am 26.07.2015 um 20:58 schrieb Doug Newgard:

...

On Sun, 26 Jul 2015 17:09:49 +0200 Peter Mattern wrote:

...
...
On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern wrote:

...
Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO? But how should such a change to PKGBUILD look like? IMO each reasonable change to PKGBUILD involves bumping pkgver and/or

Am 26.07.2015 um 16:00 schrieb Doug Newgard: pkgrel and as such makes adjusting .SRCINFO mandatory, no? And even if changes like this do exist I can hardly figure they outweigh the disadvantages stated by Remy in the meantime. There are plenty of changes that could be made to the PKGBUILD that wouldn't require a change to the .SRCINFO. Anything from formatting changes/cleanups, to restructuring functions, to switching to using install commands instead of cp, to abstracting out variables. You don't want to bump the pkgrel if they don't make any changes to the final package.

What exactly is the benefit of an isolated upload of a PKGBUILD that doesn't change the package itself at all, in particular now that Git is used and everybody has got a local checkout at hand anyway? If there should be any benefit at all it for sure doesn't outweigh disadvantages like outdated package sites or RPC issues affecting AUR helpers. And as soon as a modification of PKGBUILD does change the package at least a release bump is justified and thus an update of .SRCINFO as well.

Doug Newgard

4:27 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Tue, 28 Jul 2015 16:52:35 +0200 Peter Mattern wrote:

...

Am 26.07.2015 um 20:58 schrieb Doug Newgard:

...
On Sun, 26 Jul 2015 17:09:49 +0200 Peter Mattern wrote:

...
...
On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern wrote:

...
Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO? But how should such a change to PKGBUILD look like? IMO each reasonable change to PKGBUILD involves bumping pkgver and/or

Am 26.07.2015 um 16:00 schrieb Doug Newgard: pkgrel and as such makes adjusting .SRCINFO mandatory, no? And even if changes like this do exist I can hardly figure they outweigh the disadvantages stated by Remy in the meantime. There are plenty of changes that could be made to the PKGBUILD that wouldn't require a change to the .SRCINFO. Anything from formatting changes/cleanups, to restructuring functions, to switching to using install commands instead of cp, to abstracting out variables. You don't want to bump the pkgrel if they don't make any changes to the final package.

What exactly is the benefit of an isolated upload of a PKGBUILD that doesn't change the package itself at all, in particular now that Git is used and everybody has got a local checkout at hand anyway? If there should be any benefit at all it for sure doesn't outweigh disadvantages like outdated package sites or RPC issues affecting AUR helpers.

And as soon as a modification of PKGBUILD does change the package at least a release bump is justified and thus an update of .SRCINFO as well.

All commits are checked, not just HEAD when you push. Adding this check would make it so you cannot have commits like this at all, even if you only push later when there is another change. And how about something as simple as changing the maintainer tag?

Loui Chang

10:53 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Tue 28 Jul 2015 11:27 -0500, Doug Newgard wrote:

...

On Tue, 28 Jul 2015 16:52:35 +0200 Peter Mattern wrote:

...
What exactly is the benefit of an isolated upload of a PKGBUILD that doesn't change the package itself at all, in particular now that Git is used and everybody has got a local checkout at hand anyway? If there should be any benefit at all it for sure doesn't outweigh disadvantages like outdated package sites or RPC issues affecting AUR helpers.

And as soon as a modification of PKGBUILD does change the package at least a release bump is justified and thus an update of .SRCINFO as well.

All commits are checked, not just HEAD when you push. Adding this check would make it so you cannot have commits like this at all, even if you only push later when there is another change.

And how about something as simple as changing the maintainer tag?

Scenario: You add an install script in the PKGBUILD and you forget to add it to the commit. You add a followup commit to add the script. There are no changes to PKGBUILD.

Gordian Edenhofer

26 Jul 26 Jul

4:34 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Sun, 2015-07-26 at 14:48 +0200, Peter Mattern wrote:

...

Hello.

Considering the short time AUR 4 is in use the number of commits lacking an update of .SRCINFO seems to be rather high. The resulting problem is a cosmetic one only as the actual PKGBUILD functionality isn't affected but only the package's web page not updated accordingly. Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible.

Actually I wonder as well whether it wouldn't even be better to not have .SRCINFO written by the packagers before uploading a commit but by aurweb when commits are received. This would ensure that problems like the one stated above can't happen and I for one couldn't figure a downside so far.

Regards,

Peter Mattern

I am against calculating the .SRCINFO on the server because of the already stated security issues. However I agree that it is a growing problem for AUR helpers. A reasonable approach would be to at least remind the user through git each time a commit with no .SRCINFO was pushed. Despite being unable to rewrite the history, it is at least easy to just push the .SRCINFO afterwards. Best regards, Gordian

Marcel Korpel

5:08 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

* Gordian Edenhofer (Sun, 26 Jul 2015 18:34:28 +0200):

...

I am against calculating the .SRCINFO on the server because of the already stated security issues. However I agree that it is a growing problem for AUR helpers. A reasonable approach would be to at least remind the user through git each time a commit with no .SRCINFO was pushed.

There already is a hook that tests if .SRCINFO exists, among other files: https://projects.archlinux.org/aurweb.git/tree/git-interface/git-update.py#n... Best, Marcel

Gordian Edenhofer

5:24 p.m.

New subject: [aur-dev] .SRCINFO: handling of commits lacking an update and in general

On Sun, 2015-07-26 at 19:08 +0200, Marcel Korpel wrote:

...

* Gordian Edenhofer (Sun, 26 Jul 2015 18:34:28 +0200):

...
I am against calculating the .SRCINFO on the server because of the already stated security issues. However I agree that it is a growing problem for AUR helpers. A reasonable approach would be to at least remind the user through git each time a commit with no .SRCINFO was pushed.

There already is a hook that tests if .SRCINFO exists, among other files: https://projects.archlinux.org/aurweb.git/tree/git-interface/git -update.py#n218

Best, Marcel

I am aware of this hook, but I was recommending an additional one which would check whether the .SRINFO file is updated in the commit. I would guess the majority of PKGBUILD-modifications affect the .SRCINFO file and therefore should contain an altered .SRINFO. The proposed hook could check the pushed commit for an altered .SRCINFO file and would display a warning if it is not modified. For those changes which need no amendments to the .SRCINFO the message could simply be dismissed since the commit is pushed either way. Best Regards, Gordian

3206

Age (days ago)

3208

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

Doug Newgard
Gordian Edenhofer
Loui Chang
Marcel Korpel
Peter Mattern
Remy Marquis