Xavier wrote:

On Fri, Sep 4, 2009 at 7:58 PM, Damjan Georgievski 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

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 wrote:

Am Fri, 4 Sep 2009 19:58:48 +0200 schrieb Damjan Georgievski :

...

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

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=51142&view=markup On Sat, Sep 5, 2009 at 2:57 AM, Allan McRae 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

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 wrote:

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=51142&view=markup

...

PS: Please do not top-post.

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

wrote:

On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskan 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

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

}

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

As my advanced "PKGBUILD" mentor you really have high expections sometimes :) However, top-posting is a preference which I'm comfortable with. Allan made perfectly clear that such netiquette( http://en.wikipedia.org/wiki/Top-posting) is not welcome here, so I respectfully unsubscribe from this mailing list. Also, I'm not familiar with frugalware, nor will I ever be. I know debian package management, and I've tried to implement some basic concepts. I wish you good luck with the makepkg script and the package spitting. On Sat, Sep 5, 2009 at 10:29 PM, Xavier wrote:

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=d455a0b2cd72cd...

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 :)