Re: [arch-general] split packages documentation
Well I was referring to two packages with one PGKBUILD. Jan de Groot has come closer to that idea, see [1]. Although I think it shoule be a single pkgname field with pkg1, pkg1 names, and single pkgver, with pkgver1, pkgver2 etc. while the build section should have pkg1 pkg2, pkg3 etc. Observe that pkg1 is the head section, while pkg2, pkg3 is subsection of the build. I've implemented this concept with python, and it works. 1: http://repos.archlinux.org/viewvc.cgi/mesa/repos/extra-x86_64/PKGBUILD?revision=51142view=markup On Sat, Sep 5, 2009 at 2:57 AM, Allan McRae al...@archlinux.org wrote: Ali H. Caliskan wrote: why not use the same pkginfo with variables for both packages while using separate build section, which is the subbuild for sub packages. Huh? That sounds like you want to create two packages, requiring two build steps. I'd say that is a case for two PKGBUILDs... Allan
Re: [arch-general] split packages documentation
On Sat, Sep 05, 2009 at 02:46:49PM +0200, Ali H. Caliskan wrote: Well I was referring to two packages with one PGKBUILD. Jan de Groot has come closer to that idea, see [1]. Although I think it shoule be a single pkgname field with pkg1, pkg1 names, and single pkgver, with pkgver1, pkgver2 etc. while the build section should have pkg1 pkg2, pkg3 etc. I don't really understand what you are referring to, are you proposing a different format for PKGBUILDS for splitpkgs? If so, an example and a list of advantages compared to the momentary format would go a long way. Observe that pkg1 is the head section, while pkg2, pkg3 is subsection of the build. Not really, first the pkgname array and common variables are defined, then follows the build function and a package_$pkgname function for each package. I've implemented this concept with python, and it works. Please elaborate. What exactly have you implemented? And what does this implementation do, that makepkg 3.3 does not? 1: http://repos.archlinux.org/viewvc.cgi/mesa/repos/extra-x86_64/PKGBUILD?revision=51142view=markup PS: Please do not top-post.
Re: [arch-general] split packages documentation
Well, makepkg is script that I've studied, so it's capable of doing more
than what it should. Here is an bash illustration of what PKGBUILD should
look like according to my opinion:
pkgname=('mesa', 'libgl', 'foopkg')
pkgver=('7.5.1', '7.5.1', '1.2')
pkgrel=2
pkgdesc=(Mesa 3-D graphics libraries and include files,
Mesa 3-D graphics library and DRI software rasterizer,
foo description of some foo package)
arch=(i686 x86_64)
depends=(('libgl' 'libx11=1.2.2'
'libxt' 'gcc-libs=4.4.1'
'dri2proto=2.1' 'libdrm=2.4.13'),
('libdrm=2.4.13' 'libxxf86vm=1.0.99.1'
'libxdamage=1.1.1' 'expat=2.0.1'), '')
makedepends=('glproto=1.4.10' 'pkgconfig' 'libdrm=2.4.13'
'libxxf86vm=1.0.99.1' 'libxdamage=1.1.1' 'expat=2.0.1' 'libx11=1.2.2'
'libxt=1.0.6' 'gcc-libs=4.4.1' 'dri2proto=2.1')
url=http://mesa3d.sourceforge.net;
license=('custom')
options=(!makeflags)
source=(
ftp://ftp.freedesktop.org/pub/mesa/${pkgver}/MesaLib-${pkgver}.tar.bz2
ftp://ftp.freedesktop.org/pub/mesa/${pkgver}/MesaDemos-${pkgver}.tar.bz2
ftp://ftp.archlinux.org/other/mesa/gl-manpages-1.0.1.tar.bz2
...
#build() {
pkgsetup() {
basepkg = mesa
}
subsetup(libgl) {
build commands
}
subsetup(foopkg) {
build commands
}
On Sat, Sep 5, 2009 at 4:03 PM, Henning Garus
henning.ga...@googlemail.comwrote:
On Sat, Sep 05, 2009 at 02:46:49PM +0200, Ali H. Caliskan wrote:
Well I was referring to two packages with one PGKBUILD. Jan de Groot has
come closer to that idea, see [1]. Although I think it shoule be a single
pkgname field with pkg1, pkg1 names, and single pkgver, with pkgver1,
pkgver2 etc. while the build section should have pkg1 pkg2, pkg3 etc.
I don't really understand what you are referring to, are you proposing a
different format for PKGBUILDS for splitpkgs? If so, an example and a list
of
advantages compared to the momentary format would go a long way.
Observe that pkg1 is the head section, while pkg2, pkg3 is subsection of
the
build.
Not really, first the pkgname array and common variables are defined, then
follows the build function and a package_$pkgname function for each
package.
I've implemented this concept with python, and it works.
Please elaborate. What exactly have you implemented? And what does this
implementation do, that makepkg 3.3 does not?
1:
http://repos.archlinux.org/viewvc.cgi/mesa/repos/extra-x86_64/PKGBUILD?revision=51142view=markup
PS: Please do not top-post.
Re: [arch-general] split packages documentation
On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskanali.h.calis...@gmail.com wrote:
depends=(('libgl' 'libx11=1.2.2'
'libxt' 'gcc-libs=4.4.1'
'dri2proto=2.1' 'libdrm=2.4.13'),
('libdrm=2.4.13' 'libxxf86vm=1.0.99.1'
'libxdamage=1.1.1' 'expat=2.0.1'), '')
Bash can do array of arrays? Are you sure?
Also, stop top-posting. It's annoying
Re: [arch-general] split packages documentation
Bash can handle array of arrays, dependening on how you implement it. I'm
not that useful in that manner, since I've applied on python.
On Sat, Sep 5, 2009 at 4:36 PM, Daenyth Blank
daenyth+a...@gmail.comdaenyth%2ba...@gmail.com
wrote:
On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskanali.h.calis...@gmail.com
wrote:
depends=(('libgl' 'libx11=1.2.2'
'libxt' 'gcc-libs=4.4.1'
'dri2proto=2.1' 'libdrm=2.4.13'),
('libdrm=2.4.13' 'libxxf86vm=1.0.99.1'
'libxdamage=1.1.1' 'expat=2.0.1'), '')
Bash can do array of arrays? Are you sure?
Also, stop top-posting. It's annoying
Re: [arch-general] split packages documentation
Allan
Cheers,
and what that is supposed to achieve?
also explain the separation of the build function into separate functions
The depends array that you demonstrate does not work in bash. Can you
This message also demonstrates why top posting is annoying...
Hi,
Ali H. Caliskan wrote:
Well, makepkg is script that I've studied, so it's capable of doing more
than what it should. Here is an bash illustration of what PKGBUILD should
look like according to my opinion:
pkgname=('mesa', 'libgl', 'foopkg')
pkgver=('7.5.1', '7.5.1', '1.2')
pkgrel=2
pkgdesc=(Mesa 3-D graphics libraries and include files,
Mesa 3-D graphics library and DRI software rasterizer,
foo description of some foo package)
arch=(i686 x86_64)
depends=(('libgl' 'libx11=1.2.2'
'libxt' 'gcc-libs=4.4.1'
'dri2proto=2.1' 'libdrm=2.4.13'),
('libdrm=2.4.13' 'libxxf86vm=1.0.99.1'
'libxdamage=1.1.1' 'expat=2.0.1'), '')
makedepends=('glproto=1.4.10' 'pkgconfig' 'libdrm=2.4.13'
'libxxf86vm=1.0.99.1' 'libxdamage=1.1.1' 'expat=2.0.1' 'libx11=1.2.2'
'libxt=1.0.6' 'gcc-libs=4.4.1' 'dri2proto=2.1')
url=http://mesa3d.sourceforge.net;
license=('custom')
options=(!makeflags)
source=(
ftp://ftp.freedesktop.org/pub/mesa/${pkgver}/MesaLib-${pkgver}.tar.bz2
ftp://ftp.freedesktop.org/pub/mesa/${pkgver}/MesaDemos-${pkgver}.tar.bz2
ftp://ftp.archlinux.org/other/mesa/gl-manpages-1.0.1.tar.bz2
...
#build() {
pkgsetup() {
basepkg = mesa
}
subsetup(libgl) {
build commands
}
subsetup(foopkg) {
build commands
}
Re: [arch-general] split packages documentation
According to
On Sat, 5 Sep 2009 16:40:40 +0200
Ali H. Caliskan ali.h.calis...@gmail.com wrote:
man bash
Bash can handle array of arrays, dependening on how you implement it. I'm
not that useful in that manner, since I've applied on python.
On Sat, Sep 5, 2009 at 4:36 PM, Daenyth Blank
daenyth+a...@gmail.comdaenyth%2ba...@gmail.com
wrote:
bash only
supports
On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskanali.h.calis...@gmail.com
wrote:
depends=(('libgl' 'libx11=1.2.2'
'libxt' 'gcc-libs=4.4.1'
'dri2proto=2.1' 'libdrm=2.4.13'),
1-dimensional arrays. (Bash provides one-dimensional indexed and
associative array variables)
('libdrm=2.4.13' 'libxxf86vm=1.0.99.1'
'libxdamage=1.1.1' 'expat=2.0.1'), '')
Bash can do array of arrays? Are you sure?
Also, stop top-posting. It's annoying
Dieter
Re: [arch-general] split packages documentation
Perhaps I should start posting topless then :) Well Allan, if you can't see the benefits of this, then I shouldn't bother mentioning the KISS philosophy. Also, for instance, compiling gcc and gcc-libs would reduce time and costs for the developers. and what that is supposed to achieve? also explain the separation of the build function into separate functions The depends array that you demonstrate does not work in bash. Can you This message also demonstrates why top posting is annoying...
Re: [arch-general] split packages documentation
Ali H. Caliskan wrote: Perhaps I should start posting topless then :) Well Allan, if you can't see the benefits of this, then I shouldn't bother mentioning the KISS philosophy. Also, for instance, compiling gcc and gcc-libs would reduce time and costs for the developers. Um... you need to explain the benifits for us to see any... You mention KISS but adding extra functions to PKBUILDs without a clear need/reason it not KISS. I'm sure split packaging can be improved, but we need actual specifics and not vague ideas. Also, gcc and gcc-libs will be converted to a split package when I next build the toolchain (probably with the binutils-2.20 release). But their build steps are essentially identical so will work perfectly under the one build finction framework. So I have no idea why this justifies your suggestion. Finally, take the not to subtle hint and do not top post on the mailing lists. I do not care how good you next respose is, I will not read it if it is a top post. Allan
Re: [arch-general] split packages documentation
I did not understand 90% of what Ali H. Caliskan said, and I cannot understand how someone can keep top-posting after 3 different people asked him to comply to the bottom-posting rule, but well... I just wanted to say that the example he gave reminded me of frugalware's handling of split packages : http://mailman.archlinux.org/pipermail/pacman-dev/2008-June/006778.html I am sorry I did not realize that 1 year earlier, but I much prefer their solution (or probably a mix between both), because it allows easy parsing of pkgbuilds using bash. The current format is quite hard (and inefficient) to parse : http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=d455a0b2cd72cd08b7b6cde878a29841f77a041e#patch2 However the current format looks much nicer and readable, and this might be a more important aspect. And more importantly, it's already in use and working :)
Re: [arch-general] split packages documentation
On Fri, Sep 4, 2009 at 7:58 PM, Damjan Georgievskigdam...@gmail.com wrote: I've been looking for documentation about split packages in the usual places (man PKGBUILD, the wiki) but couldn't find any.. am I missing something or this is a feature-not-implemented? do we have the same PKGBUILD man page ? :) man PKGBUILD /split PACKAGE SPLITTING makepkg supports building multiple packages from a single PKGBUILD. This is achieved by assigning an array of package names to the pkgname directive. Each split package uses a corresponding packaging function with name package_foo(), where foo is the name of the split package. All options and directives for the split packages default to the global values given within the PKGBUILD. However, some of these can be overridden within each split package’s packaging function. The following variables can be overridden: pkgdesc, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options and install. An optional global directive is available when building a split package: pkgbase The name used to refer to the group of packages in the output of makepkg and in the naming of source-only tarballs. If not specified, the first element in the pkgname array is used.
Re: [arch-general] split packages documentation
Xavier wrote: On Fri, Sep 4, 2009 at 7:58 PM, Damjan Georgievskigdam...@gmail.com wrote: I've been looking for documentation about split packages in the usual places (man PKGBUILD, the wiki) but couldn't find any.. am I missing something or this is a feature-not-implemented? do we have the same PKGBUILD man page ? :) man PKGBUILD /split PACKAGE SPLITTING makepkg supports building multiple packages from a single PKGBUILD. This is achieved by assigning an array of package names to the pkgname directive. Each split package uses a corresponding packaging function with name package_foo(), where foo is the name of the split package. All options and directives for the split packages default to the global values given within the PKGBUILD. However, some of these can be overridden within each split package’s packaging function. The following variables can be overridden: pkgdesc, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options and install. An optional global directive is available when building a split package: pkgbase The name used to refer to the group of packages in the output of makepkg and in the naming of source-only tarballs. If not specified, the first element in the pkgname array is used. and don't forget about the proto /usr/share/pacman/PKGBUILD-split.proto -- Ionut
Re: [arch-general] split packages documentation
Am Fri, 4 Sep 2009 19:58:48 +0200 schrieb Damjan Georgievski gdam...@gmail.com: I've been looking for documentation about split packages in the usual places (man PKGBUILD, the wiki) but couldn't find any.. am I missing something or this is a feature-not-implemented? http://allanmcrae.com/2009/07/new-pkgbuild-syntax-options-with-pacman-33/ the split package support is still a bit tricky and lacking some features. we will probably add more docs to the wiki when pacman 3.4 comes out. -Andy
Re: [arch-general] split packages documentation
why not use the same pkginfo with variables for both packages while using separate build section, which is the subbuild for sub packages. On Fri, Sep 4, 2009 at 8:09 PM, Andreas Radke a.ra...@arcor.de wrote: Am Fri, 4 Sep 2009 19:58:48 +0200 schrieb Damjan Georgievski gdam...@gmail.com: I've been looking for documentation about split packages in the usual places (man PKGBUILD, the wiki) but couldn't find any.. am I missing something or this is a feature-not-implemented? http://allanmcrae.com/2009/07/new-pkgbuild-syntax-options-with-pacman-33/ the split package support is still a bit tricky and lacking some features. we will probably add more docs to the wiki when pacman 3.4 comes out. -Andy
Re: [arch-general] split packages documentation
Ali H. Caliskan wrote: why not use the same pkginfo with variables for both packages while using separate build section, which is the subbuild for sub packages. Huh? That sounds like you want to create two packages, requiring two build steps. I'd say that is a case for two PKGBUILDs... Allan
