[arch-general] makepkg patch - generate .SRCINFO file when running "--source"
Hello list,
Here is a patch against makepkg from git which introduces a new function
"write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO
one - when "makepkg --source" is run and then it is added to the src.tar.gz
archive.
I think having such a file is an important step for getting split packages to
the AUR. It is also useful for third party applications. Since this file is
generated during making the source archive, there is no need for parsing/sourcing
the PKGBUILD everytime meta infos are needed afterwards.
This is also a way of standardizing the source archive.
.SRCINFO looks like (generated for gcc from core):
"
# Generated by makepkg 3.4.0
# Tue Jul 27 12:56:38 UTC 2010
global pkgbase = gcc
global pkgname = gcc
global pkgname = gcc-libs
global pkgname = gcc-fortran
global pkgname = gcc-objc
global pkgname = gcc-ada
global pkgver = 4.5.0-6
global pkgdesc = The GNU Compiler Collection
global url = http://gcc.gnu.org
global packager = Vlad George
On Tuesday 27 July 2010 15:25:56 vlad wrote: > Hello list, > > Here is a patch against makepkg from git which introduces a new function > "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO > one - when "makepkg --source" is run and then it is added to the src.tar.gz > archive. snip > global makedepends = binutils>=2.20.1 > global makedepends = libmpc>=0.8.2-2 > global makedepends = cloog-ppl>=0.15.8 What about packages that define source / depends / ... depending on the used arch ? For example: ------------- if [ $CARCH == 'x86_64' ]; then _pkgarch=... md5sums=... depends=... else ... fi source=("...${_pk garch}.tar.gz") ------------- jakob
On Tue, Jul 27, 2010 at 03:38:10PM +0200, Jakob Gruber wrote: > On Tuesday 27 July 2010 15:25:56 vlad wrote: > > Hello list, > > > > Here is a > patch against makepkg from git which introduces a new function > > > "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO > > one > - when "makepkg --source" is run and then it is added to the src.tar.gz > > > archive. > > snip > > > global makedepends = binutils>=2.20.1 > > global makedepends > = libmpc>=0.8.2-2 > > global makedepends = cloog-ppl>=0.15.8 > > What about > packages that define source / depends / ... depending on the used arch ? For > example: > > ------------- > > if [ $CARCH == 'x86_64' ]; > then > _pkgarch=... > md5sums=... > depends=... > else > ... > fi As it is now handled in AUR, there is imo no sane way to handle this. I propose that there should be a default way of writing this in PKGBUILDs. I think of smth like: " [[ $CARCH == "i686" ]] && .. " And only this should be allowed. This is then easily parseable. I know this is quite restrictive, but it is also an approach to standardize the source archives. As you see, for now it's a pita to correctly display this in the AUR web interface and also for other scripts to parse this. --
Why not make new arrays? i686depends, x86_64depends, i686source, etc. On Tue, Jul 27, 2010 at 8:51 AM, vladwrote: > On Tue, Jul 27, 2010 at 03:38:10PM +0200, Jakob Gruber wrote: > > On Tuesday 27 July 2010 15:25:56 vlad wrote: > > > Hello list, > > > > > > Here is a > > patch against makepkg from git which introduces a new function > > > > > "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO > > > one > > - when "makepkg --source" is run and then it is added to the src.tar.gz > > > > > archive. > > > > snip > > > > > global makedepends = binutils>=2.20.1 > > > global makedepends > > = libmpc>=0.8.2-2 > > > global makedepends = cloog-ppl>=0.15.8 > > > > What about > > packages that define source / depends / ... depending on the used arch ? > For > > example: > > > > ------------- > > > > if [ $CARCH == 'x86_64' ]; > > then > > _pkgarch=... > > md5sums=... > > depends=... > > else > > ... > > fi > As it is now handled in AUR, there is imo no sane way to handle this. > I propose that there should be a default way of writing this in PKGBUILDs. > I think of smth like: > " > [[ $CARCH == "i686" ]] && .. > " > And only this should be allowed. This is then easily parseable. > I know this is quite restrictive, but it is also an approach to > standardize the source archives. As you see, for now it's a pita to > correctly display this in the AUR web interface and also for other > scripts to parse this. > > -- >
On Tue, Jul 27, 2010 at 13:36, Muhammed Uluyol
Why not make new arrays? i686depends, x86_64depends, i686source, etc. Please don't...
Also, please bottom post on this list.
On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
Here is a patch against makepkg from git which introduces a new function "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO one - when "makepkg --source" is run and then it is added to the src.tar.gz archive. I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive.
.SRCINFO looks like (generated for gcc from core):
Nice. :D This is something that I had been brainstorming too. You should submit it to the pacman-dev list and/or the pacman bug tracker.
On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote:
On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
Here is a patch against makepkg from git which introduces a new function "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO one - when "makepkg --source" is run and then it is added to the src.tar.gz archive. I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive.
.SRCINFO looks like (generated for gcc from core):
Nice. :D This is something that I had been brainstorming too. Hehe, that's why I did it. I wanted to give this a push. You should submit it to the pacman-dev list and/or the pacman bug tracker. Is pacman-dev public or open for non-devs?
--
On Mon 02 Aug 2010 17:03 +0200, vlad wrote:
On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote:
On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
Here is a patch against makepkg from git which introduces a new function "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO one - when "makepkg --source" is run and then it is added to the src.tar.gz archive.
I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive.
.SRCINFO looks like (generated for gcc from core):
Nice. :D This is something that I had been brainstorming too.
Hehe, that's why I did it. I wanted to give this a push.
You should submit it to the pacman-dev list and/or the pacman bug tracker.
Is pacman-dev public or open for non-devs?
Yes. It's open to anybody. Just subscribe first.
On Mon, Aug 2, 2010 at 10:03 AM, vlad
On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote:
On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
Here is a patch against makepkg from git which introduces a new function "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO one - when "makepkg --source" is run and then it is added to the src.tar.gz archive. I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive.
.SRCINFO looks like (generated for gcc from core):
Nice. :D This is something that I had been brainstorming too. Hehe, that's why I did it. I wanted to give this a push. You should submit it to the pacman-dev list and/or the pacman bug tracker. Is pacman-dev public or open for non-devs?
Public, but you have to sign up. -Dan
participants (6)
-
Daenyth Blank
-
Dan McGee
-
Jakob Gruber
-
Loui Chang
-
Muhammed Uluyol
-
vlad