[aur-general] Ho to update .SRCINFO without creating a tarball?
Hello, I'm doing my first steps with AUR 4.0 and I'm asked to commit both, PKGBUILD and .SRCINFO. .SRCINFO is automatically created with "makepkg --source", but there is no need for a tarball when pushing to GIT. So what I think that would be useful is something like "makepkg --upgradesrcinfo" or something like that. I something like this already available? Manuel
On Sat, 23 May 2015 at 11:34:38, Manuel Reimer wrote:
Hello,
I'm doing my first steps with AUR 4.0 and I'm asked to commit both, PKGBUILD and .SRCINFO.
.SRCINFO is automatically created with "makepkg --source", but there is no need for a tarball when pushing to GIT. So what I think that would be useful is something like "makepkg --upgradesrcinfo" or something like that.
I something like this already available?
You can use mksrcinfo from pkgbuild-introspection. Maybe we should add some tips to the Arch wiki.
Manuel
Lukas, On Sat, 23 May 2015, Lukas Fleischer wrote:
You can use mksrcinfo from pkgbuild-introspection. Maybe we should add some tips to the Arch wiki.
You mean from pkgbuild-introspection-git? Which, interestingly enough, is not on AUR 4 yet. --brian
* "Brian F. G. Bidulock" <bidulock@openss7.org> (Sat, 23 May 2015 21:51:18 -0600):
You mean from pkgbuild-introspection-git? Which, interestingly enough, is not on AUR 4 yet.
Please use https://aur.archlinux.org/packages/pkgbuild-introspection-git Best, Marcel
On Sat, 23 May 2015 11:34:38 +0200 Manuel Reimer <manuel.reimer@gmx.de> wrote:
Hello,
I'm doing my first steps with AUR 4.0 and I'm asked to commit both, PKGBUILD and .SRCINFO.
.SRCINFO is automatically created with "makepkg --source", but there is no need for a tarball when pushing to GIT. So what I think that would be useful is something like "makepkg --upgradesrcinfo" or something like that.
I something like this already available?
Manuel
I'd be happy if there was at least a reasonable description of .SCRINFO on the wiki. There's a glossy version here: https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_metadata But there should be more, given that it is so important. It should have its own page, like PKGBUILD does. And someone who knows it far better than I should create it. -- Jonathan Arnold Webstream: http://hieronymus.soup.io If you want to go fast, go alone. If you want to go far, you need a team ~ John Wooden
* Jonathan Arnold <jdarnold@buddydog.org> (Wed, 27 May 2015 07:56:20 -0400):
I'd be happy if there was at least a reasonable description of .SCRINFO on the wiki. There's a glossy version here:
https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_metadata
But there should be more, given that it is so important. It should have its own page, like PKGBUILD does.
Why do you need such a description? It just contains the metadata in PKGBUILD and you really shouldn't create or change it yourself. Best, Marcel
On Wed, 27 May 2015 16:25:13 +0200 Marcel Korpel <marcel.korpel@gmail.com> wrote:
* Jonathan Arnold <jdarnold@buddydog.org> (Wed, 27 May 2015 07:56:20 -0400):
I'd be happy if there was at least a reasonable description of .SCRINFO on the wiki. There's a glossy version here:
https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_metadata
But there should be more, given that it is so important. It should have its own page, like PKGBUILD does.
Why do you need such a description? It just contains the metadata in PKGBUILD and you really shouldn't create or change it yourself.
Best, Marcel
Well, for one, there's no mention on the wiki on how to generate this file. For another, it seems pretty easy to generate by hand, as the description indicates (nowhere does it say it gets generated). -- Jonathan Arnold Webstream: http://hieronymus.soup.io If you want to go fast, go alone. If you want to go far, you need a team ~ John Wooden
* Jonathan Arnold <jdarnold@buddydog.org> (Wed, 27 May 2015 15:18:43 -0400):
Well, for one, there's no mention on the wiki on how to generate this file. For another, it seems pretty easy to generate by hand, as the description indicates (nowhere does it say it gets generated).
Just use mksrcinfo from pkgbuild-introspection-git at https://aur.archlinux.org/packages/pkgbuild-introspection-git (I suppose mksrcinfo will be incorporated into pkgbuild-introspection). Generating such a file manually is error-prone, using mksrcinfo ensures that the file is exactly what AURweb needs. Best, Marcel
Generating such a file manually is error-prone, using mksrcinfo ensures that the file is exactly what AURweb needs.
I believe that is what he is saying should be in the wiki. And since there are so many questions around it this past week on the mailing list, it might be a good idea to have it on record for new maintainers when they go to submit their first packages as well. - Justin
* Justin Dray <justin@dray.be> (Wed, 27 May 2015 22:36:03 +0000):
Generating such a file manually is error-prone, using mksrcinfo ensures that the file is exactly what AURweb needs.
I believe that is what he is saying should be in the wiki.
I understand, and I edited the wiki a bit: https://wiki.archlinux.org/index.php/Arch_User_Repository#Submitting_package... Best, Marcel
On Thu, 28 May 2015 01:24:38 +0200 Marcel Korpel <marcel.korpel@gmail.com> wrote:
I understand, and I edited the wiki a bit: https://wiki.archlinux.org/index.php/Arch_User_Repository#Submitting_package...
Best, Marcel
Since you're at it, why don't you make the "git push" part a bit clearer, since many of us are unfamiliar with git? Ie, you could put the steps like that: 1. Create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 2. Clone the (initially empty) package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ 3. Change into the directory: $ cd foobar/ 3. Copy the relevant files from previous AUR folder: $ cp ~/AUR/coolvlviewer/* ./ 4. mksrcinfo from the package blah-blah $ mksrcinfo 5. $ git add . 6. $ git commit -m "Initial commit" (or whatnot) 7. Push: $ git push -u origin master -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»
* Νῖκος Θεοδώρου <ntheo1979@gmail.com> (Thu, 28 May 2015 12:49:07 +0300):
Since you're at it, why don't you make the "git push" part a bit clearer, since many of us are unfamiliar with git?
Good point, but we'll also have to add a default .gitignore file, otherwise everything in src/ and pkg/ and all downloaded files will be automatically included in commits. I think we should wait until [1] gets merged into that project: then that file could serve as a default .gitignore file for future AUR packages.
1. Create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 2. Clone the (initially empty) package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ 3. Change into the directory: $ cd foobar/ 3. Copy the relevant files from previous AUR folder: $ cp ~/AUR/coolvlviewer/* ./ 4. mksrcinfo from the package blah-blah $ mksrcinfo
At this point, a default .gitignore should be placed in .
5. $ git add . 6. $ git commit -m "Initial commit" (or whatnot) 7. Push: $ git push -u origin master
And: After future changes in PKGBUILDs run these commands again: $ git add . $ git commit -m "Change summary" $ git push Where "Change summary" contains the new package version or a description of other changes you made. Something like that? Best, Marcel [1] https://github.com/github/gitignore/pull/1534
On Thu, 28 May 2015 13:14:11 +0200 Marcel Korpel <marcel.korpel@gmail.com> wrote:
I think we should wait until [1] gets merged into that project: then that file could serve as a default .gitignore file for future AUR packages.
Wouldn't it be just easier to recommend that one a) edit the PKGBUILD b) run makepkg -g and change the sums in the PKGBUILD b) run makepkg in order to build the package c) run pacman -U in order to install the package (if the maintainer actually uses it) d) delete (by hand) unnecessary files and directories and then e) git add . etc in order to update? I mean, isn't .gitignore an unnecessary complication? No one will want to keep src/ and pkg/ etc after they are done anyway. Since they will delete them after (e), they might as well do it before (e). Just my opinion.
Something like that? If you want to go that way, yes, something like that.
-- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»
* Marcel Korpel <marcel.korpel@gmail.com> (Thu, 28 May 2015 13:14:11 +0200):
At this point, a default .gitignore should be placed in .
One more addition: in case of a package that downloads from VCS sources, the download directory created by makepkg (containing the source tree) should be added to .gitignore. For instance, a package named foobar-git will likely result in a download directory named foobar/ [1]; this name should be included in .gitignore. [1] Is this true? After all, one can override the default download directory in the source array. Best, Marcel
* Νῖκος Θεοδώρου <ntheo1979@gmail.com> (Thu, 28 May 2015 14:23:41 +0300):
On Thu, 28 May 2015 13:14:11 +0200 Marcel Korpel <marcel.korpel@gmail.com> wrote:
I think we should wait until [1] gets merged into that project: then that file could serve as a default .gitignore file for future AUR packages.
Wouldn't it be just easier to recommend that one a) edit the PKGBUILD b) run makepkg -g and change the sums in the PKGBUILD
You can do this automatically by running updpkgsums.
b) run makepkg in order to build the package c) run pacman -U in order to install the package (if the maintainer actually uses it) d) delete (by hand) unnecessary files and directories and then e) git add . etc in order to update?
I mean, isn't .gitignore an unnecessary complication? No one will want to keep src/ and pkg/ etc after they are done anyway. Since they will delete them after (e), they might as well do it before (e). Just my opinion.
That depends on the workflow of the maintainer. I like to let those files stick around, so I can easily downgrade a package when necessary without redownloading and/or rebuilding sources. Especially VCS sources (mentioned in my other mail) shouldn't be deleted, resulting in downloading the complete tree over and over again. What do others do? Best, Marcel
On Thu, 28 May 2015 13:34:35 +0200 Marcel Korpel <marcel.korpel@gmail.com> wrote:
* Νῖκος Θεοδώρου <ntheo1979@gmail.com> (Thu, 28 May 2015 14:23:41 +0300):
I mean, isn't .gitignore an unnecessary complication? No one will want to keep src/ and pkg/ etc after they are done anyway. Since they will delete them after (e), they might as well do it before (e). Just my opinion.
That depends on the workflow of the maintainer. I like to let those files stick around, so I can easily downgrade a package when necessary without redownloading and/or rebuilding sources.
Especially VCS sources (mentioned in my other mail) shouldn't be deleted, resulting in downloading the complete tree over and over again.
Fair enough. -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»
On Thu, 28 May 2015 at 11:49:07, Νῖκος Θεοδώρου wrote:
[...] Since you're at it, why don't you make the "git push" part a bit clearer, since many of us are unfamiliar with git? Ie, you could put the steps like that: 1. Create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 2. Clone the (initially empty) package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ 3. Change into the directory: $ cd foobar/ 3. Copy the relevant files from previous AUR folder: $ cp ~/AUR/coolvlviewer/* ./ 4. mksrcinfo from the package blah-blah $ mksrcinfo 5. $ git add . 6. $ git commit -m "Initial commit" (or whatnot) 7. Push: $ git push -u origin master [...]
Added a simplified version of this to the wiki.
participants (7)
-
Brian F. G. Bidulock
-
Jonathan Arnold
-
Justin Dray
-
Lukas Fleischer
-
Manuel Reimer
-
Marcel Korpel
-
Νῖκος Θεοδώρου