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 donvla@users.sourceforge.net global builddate = 1280235398 global source = ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/gcc-core-4.5-20100610.tar.bz2 global source = ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/gcc-g++-4.5-20100610.tar.bz2 global source = ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/gcc-fortran-4.5-20100610.tar.bz2 global source = ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/gcc-objc-4.5-20100610.tar.bz2 global source = ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/gcc-ada-4.5-20100610.tar.bz2 global source = ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/libstdc++-man.20100312.tar.bz2 global source = gcc_pure64.patch global source = gcc-hash-style-both.patch global source = r160561.patch global license = GPL global license = LGPL global license = custom global arch = i686 global arch = x86_64 global makedepends = binutils>=2.20.1 global makedepends = libmpc>=0.8.2-2 global makedepends = cloog-ppl>=0.15.8 global makedepends = libelf global makedepends = gcc-ada gcc depends = binutils>=2.20.1 gcc depends = libmpc>=0.8.1-2 gcc depends = cloog-ppl>=0.15.8 gcc depends = libelf gcc groups = base-devel gcc install = gcc.install gcc-libs pkgdesc = Runtime libraries shipped by GCC for C and C++ languages gcc-libs groups = base gcc-libs depends = glibc>=2.11.1-2 gcc-libs install = gcc-libs.install gcc-fortran pkgdesc = Fortran front-end for GCC gcc-fortran depends = gcc=4.5.0-6 gcc-fortran install = gcc-fortran.install gcc-objc pkgdesc = Objective-C front-end for GCC gcc-objc depends = gcc=4.5.0-6 gcc-ada pkgdesc = Ada front-end for GCC (GNAT) gcc-ada depends = gcc=4.5.0-6 gcc-ada install = gcc-ada.install "
As you see this file contains of different parts separated by a leading tag. "global" denotes the global PKGBUILD vars and the name of the split package denotes the local package variables. However, this is just a first formatting approach. This can be changed according to further needs. I think this is a clear and easily readable/parseable output. Note that "packager" defaults to the person who actually build the source archive. Perhaps this has to be changed to AUR user name, not to the makepkg.conf PACKAGER entry.
Vlad
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, vlad vla@uni-bonn.de wrote:
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 uluyol0@gmail.com wrote:
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 vla@uni-bonn.de 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?
Public, but you have to sign up.
-Dan
arch-general@lists.archlinux.org