On 03/08/10 19:22, vlad wrote:
Hello,
Here is a mail I sent to the arch-general list containing a patch for
makepkg which generates a .SRCINFO file when running "makepkg --source".
Below I'll make some more comments, present some more ideas on this
topic.
Overall, I am quite happy with this idea. Obviously we could tidy up
the implementation a bit at a later stage.
First I think we need to get the formatting issues sorted, as once the
format is set, it becomes very difficult to change.
<snip>
.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
This needs to be separated into pkgver/pkgrel as both of these can be
overridden in split packages.
...
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
I think the whole "global"/"splitpkg" leading entry seems fine.
<snip>
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.
Pacman and makepkg are distribution agnostic so the user would have to
change the PACKAGER entry if it was deemed necessary to match the AUR
username (which it should not have to...).
The main idea behind this is to unify and standardize how PKGBUILDs are
handled (mainly AUR). For now information about a package has to be parsed from
the
PKGBUILD which creates a big overhead and has many security holes.
There are some more problems with this. As a user said, there is a
problem with if clauses for different arches. Imo there is no sane way
to handle this. So we should try a different approach.
A possible one is to restrict the way architecture specific variables
are written to PKGBUILDs; perhaps only smth like:
"[[ $CARCH == "i686" ]]&& sources= ... "
Though this is quite restrictive, and I see a discussion coming up why this
and not the other way.
I am against imposing restrictions to formatting like that as there is
always something that needs to be done differently...
A more elegant way - which I personally prefer - is to introduce a new
function "arch_$CARCH" to PKGBUILDs. Actually these are two functions,
arch_i686 and
arch_x86_64, one for each architecture. These functions appear in the
first (global) part of the PKGBUILD before the build/package functions
and contain arch specific variables. This may look like (eg for new wine
PKGBUILD):
"
arch=(i686 x86_64)
license=(LGPL)
arch_i686() {
depends=(fontconfig mesa libxcursor libxrandr libxdamage libxxf86dga
alsa-lib)
makedepends=(autoconf ncurses bison perl fontforge flex prelink
'gcc>=4.5.0-2' cross32-gcc libgphoto2 giflib libxpm libpng libxinerama
libxcomposite \
libxmu libxxf86vm libxml2 libxslt libldap lcms mpg123 openal
esound jack cups sane samba)
optdepends=(libgphoto2 giflib libpng libldap lcms libxml2 mpg123 openal
esound jack cups sane samba)
}
arch_x86_64() {
depends=(...)
}
source=("stuff")
md5sums=("numbers")
build() {
....
}
"
You get the point.
Note that only vars are allowed in these functions; other entries are ignored.
There should also be a list/array of allowed vars (like "splitpkg_overrides").
There are: depends, makedepends, optdepends, source, checksums.
Note that this does not affect the build/package functions in any way.
The main advantages are:
* This is a unified way to handle arch specific vars in PKGBUILDs.
There are no dirty hacks, no barely readable if clauses, etc.
* This is easy to parse - if needed - and easily integrable into makepkg.
After sourcing the buildfile, you can first check if there is such a function
and than simply run it (eg: "declare -F arch_$CARCH&& arch_$CARCH").
In combination with .SRCINFO there is no need to parse the
PKGBUILD at all afterwards.
* And for the .SRCINFO file: with these functions you can expand (only
an example - as I said above, this formatting is just one possibility) the
separation tags to "global_i686" and "global_x86_64" which point to
the arch specific vars. This completes the output/writing of this file.
I am not sure about this. Despite it being simpler on the surface, how
would you handle this within a split package function? I could see the
need for different dependencies depending on architecture within a split
package.
Allan
