self-editing PKGBUILD ?

matthiaskrgr · 2012-04-08 17:34:37

The idea is the following:

The actual PKGBUILD for the project is hosted on github where people can fork and edit it.
This would mean that the maintainer of the pkgbuild would have to sync it to aur everytime it has been updated.
To solve this, I thought about a pkgbuild which updates itself:

UPDATE

pkgname=(test)
pkgver=1
pkgrel=1
arch=('any')
url='http://www.example.com/'
license=('GPL')
build() {
	cd ../
	curl http://aur.archlinux.org/packages/al/alsi/PKGBUILD > PKGBUILD
	echo "# above you can see the PKGBUILD which is goint go be build" >> PKGBUILD
	echo "# press q to continue" >> PKGBUILD
	echo "# press ctrl + c   and then  q   to abort" >> PKGBUILD
	cat PKGBUILD | less || exit
	makepkg
	true
	exit
}

package() {
true
exit
}

My question is if this is allowed or if the pkgbuild would be removed from aur due to violation of some terms or whatever.
Any comments?

Old version:

pkgname=(test)
pkgver=1
pkgrel=1
arch=('any')
url='http://www.example.com/'
license=('GPL')
build() {
	cd ../
        #destination to upstream PKGBUILD, chose that one as an example
	curl http://aur.archlinux.org/packages/al/alsi/PKGBUILD > PKGBUILD
	makepkg
	true
	exit
}

package() {
      true
      exit
}

Last edited by matthiaskrgr (2012-04-08 20:37:15)

karol · 2012-04-08 17:48:19

matthiaskrgr wrote:

The actual PKGBUILD for the project is hosted on github where people can fork and edit it.

Why can't the other, forked projects upload their own PKGBUILDs?
What edits to the PKGBUILD are we talking about?

Awebb · 2012-04-08 18:08:53

I don't think matthiaskrgr wasn't talking about updating the PKGBUILD because of the forks. I think the OP only named a github feature, in the way you introduce something completely new to an audience. The PKGBUILD updates itself the moment the project changes on github and requires an update to the PKGBUILD, or better: The PKGBUILD in the AUR is only a dummy that fetches the PKGBUILD from the github page and installs it.

I'm not sure if I like this.

Trilby · 2012-04-08 18:09:31

I would hope these didn't become common. How many levels of makepkg recursion would be allowed? How would you know if you were about to try to run makepkg on an infinitely recursive PKGBUILD?

karol · 2012-04-08 18:13:12

So it's all because someone wants to automate updating PKGBUILDs in the AUR?

Oxyd · 2012-04-08 18:20:45

Guess it might work for -git packages that don't really have version numbers but rather users are expected to track them as they wish.

For ordinary packages, however -- how would the version number of the PKGBUILD in AUR ever get changed? Imagine the author releases a new version of the package, the PKGBUILD on Github gets updated, but the AUR one stays the same -- users won't even notice the update unless they explicitely track the Github PKGBUILD. AUR helpers won't notice as the AUR PKGBUILD still lists exactly the same version. So to fix this, you'd have to bump the AUR PKGBUILD each time a new version is released. But then you can just upload the whole PKGBUILD from Github to AUR since you're already messing with it anyway.

karol · 2012-04-08 18:26:22

My thoughts exactly.

You should also inspect the PKGBUILD before using it. How would that work in this scenario?

matthiaskrgr · 2012-04-08 18:56:08

Oxyd wrote:

Guess it might work for -git packages that don't really have version numbers but rather users are expected to track them as they wish.
For ordinary packages, however -- how would the version number of the PKGBUILD in AUR ever get changed? Imagine the author releases a new version of the package, the PKGBUILD on Github gets updated, but the AUR one stays the same -- users won't even notice the update unless they explicitely track the Github PKGBUILD. AUR helpers won't notice as the AUR PKGBUILD still lists exactly the same version. So to fix this, you'd have to bump the AUR PKGBUILD each time a new version is released. But then you can just upload the whole PKGBUILD from Github to AUR since you're already messing with it anyway.

Indeed, I only had the -git (or -svn) packages in mind as usecase. For packages with "regular" release-cycles, this won't make much sense.

Oxyd · 2012-04-08 18:58:14

In that case, it doesn't seem very useful either. These -git/-svn PKGBUILDs generally only do a git pull and then launch the build script. There's not much surface for a change to justify this in my opinion. Especially since the build script itself is going to be pulled from the repo.

Are you trying to solve some concrete problem or are you just toying around with ideas here?

matthiaskrgr · 2012-04-08 19:05:18

karol wrote:

My thoughts exactly.
You should also inspect the PKGBUILD before using it. How would that work in this scenario?

pkgname=(test)
pkgver=1
pkgrel=1
arch=('any')
url='http://www.example.com/'
license=('GPL')
build() {
	cd ../
	curl http://aur.archlinux.org/packages/al/alsi/PKGBUILD > PKGBUILD
	echo "# above you can see the PKGBUILD which is goint go be build" >> PKGBUILD
	echo "# press q to continue" >> PKGBUILD
	echo "# press ctrl + c   and then  q   to abort" >> PKGBUILD
	cat PKGBUILD | less || exit
	makepkg
	true
	exit
}

package() {
true
exit
}

karol · 2012-04-08 19:30:58

OK, but why not just update the PKGBUILD the usual way?

I see a useless cat instead of an $EDITOR and calling makepkg from inside the PKGBUILD ... hmmmm.

I know what does 'cd ../' do, but why??
Oh, I think it's not a complete PKGBUILD but one that deals with my question about viewing the final PKGBUILD. OK then.

Last edited by karol (2012-04-08 19:34:29)

.:B:. · 2012-04-08 19:45:18

I think it defeats the purpose of the AUR.

Best place to ask is the AUR mailing list.

Last edited by .:B:. (2012-04-08 19:45:31)

matthiaskrgr · 2012-04-08 20:17:59

Oxyd wrote:

In that case, it doesn't seem very useful either. These -git/-svn PKGBUILDs generally only do a git pull and then launch the build script. There's not much surface for a change to justify this in my opinion. Especially since the build script itself is going to be pulled from the repo.

Mmhh.
Well, there could be some pkgbuild which first pulls the git repo, then moves the cd's itself into the the location of the pkgbuild, cp's the .git dir of the original pulled repo into the current dir (so we don't need to download the entire repo again) and then runs makepkg.
But this would be a makepkg within a makepkg again.

Are you trying to solve some concrete problem or are you just toying around with ideas here?

Well, I think it ends up to be more like playing around now.

matthiaskrgr · 2012-04-08 20:33:15

karol wrote:

OK, but why not just update the PKGBUILD the usual way?
I see a useless cat instead of an $EDITOR and calling makepkg from inside the PKGBUILD ... hmmmm.
I know what does 'cd ../' do, but why??
Oh, I think it's not a complete PKGBUILD but one that deals with my question about viewing the final PKGBUILD. OK then.

Mmh, the $EDITOR is a nice idea but I don't seem to be able to easily terminate the process using nano.
Without the second makepkg, the "new" pkgbuild isn't build.

tomk · 2012-04-08 20:33:49

I got as far as

build() {
	cd ../
        #destination to upstream PKGBUILD, chose that one as an example
	curl http://aur.archlinux.org/packages/al/alsi/PKGBUILD > PKGBUILD
	makepkg
	true
	exit
}

but couldn't read any further, as a result of mental and physical incapacitation caused by excessive lol'ing, rofl'ing, and lmao'ing.

Jookia · 2012-04-08 21:54:09

That's all fine and dandy until I go postal and commit 'rm -rf /' in the PKGBUILD.

matthiaskrgr · 2012-04-08 22:01:15

Jookia wrote:

That's all fine and dandy until I go postal and commit 'rm -rf /' in the PKGBUILD.

quote from the aur page
"Unsupported packages are user produced content. Any use of the provided files is at your own risk."
Also one should never run makepkg as su...

mcmillan · 2012-04-08 22:15:19

And normally people can look at the PKGBUILD before trying to build it, while your pkgbuild passes off to another pkgbuild at a different location. Yes people should then look at that other pkgbuild, but then why would they use the one you upload to the AUR in that case?

If all you're trying to do is keep things synced with a git you can use the standard git pkgbuild that already exists and downloads the latest changes before building.

synthead · 2012-04-23 08:39:57

No no no no and no. PKGBUILDs should never change as they're being built with the exception of packages that track development branches (subversion, git, etc.)

Arch Linux

#1 2012-04-08 17:34:37

self-editing PKGBUILD ?

#2 2012-04-08 17:48:19

Re: self-editing PKGBUILD ?

#3 2012-04-08 18:08:53

Re: self-editing PKGBUILD ?

#4 2012-04-08 18:09:31

Re: self-editing PKGBUILD ?

#5 2012-04-08 18:13:12

Re: self-editing PKGBUILD ?

#6 2012-04-08 18:20:45

Re: self-editing PKGBUILD ?

#7 2012-04-08 18:26:22

Re: self-editing PKGBUILD ?

#8 2012-04-08 18:56:08

Re: self-editing PKGBUILD ?

#9 2012-04-08 18:58:14

Re: self-editing PKGBUILD ?

#10 2012-04-08 19:05:18

Re: self-editing PKGBUILD ?

#11 2012-04-08 19:30:58

Re: self-editing PKGBUILD ?

#12 2012-04-08 19:45:18

Re: self-editing PKGBUILD ?

#13 2012-04-08 20:17:59

Re: self-editing PKGBUILD ?

#14 2012-04-08 20:33:15

Re: self-editing PKGBUILD ?

#15 2012-04-08 20:33:49

Re: self-editing PKGBUILD ?

#16 2012-04-08 21:54:09

Re: self-editing PKGBUILD ?

#17 2012-04-08 22:01:15

Re: self-editing PKGBUILD ?

#18 2012-04-08 22:15:19

Re: self-editing PKGBUILD ?

#19 2012-04-23 08:39:57

Re: self-editing PKGBUILD ?

Board footer