split packages documentation

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

split packages documentation

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?

--
damjan
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Xavier-3
On Fri, Sep 4, 2009 at 7:58 PM, Damjan Georgievski<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ionut Biru
Xavier wrote:

> On Fri, Sep 4, 2009 at 7:58 PM, Damjan Georgievski<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Andreas Radke
In reply to this post by Damjan Georgievski
Am Fri, 4 Sep 2009 19:58:48 +0200
schrieb Damjan Georgievski <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
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 <[hidden email]> wrote:

> Am Fri, 4 Sep 2009 19:58:48 +0200
> schrieb Damjan Georgievski <[hidden email]>:
>
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Allan McRae
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


Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
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 <[hidden email]> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Henning Garus
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.
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
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
<[hidden email]>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.
>
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Daenyth Blank
On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskan<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
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
<[hidden email]<daenyth%[hidden email]>
> wrote:

> On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskan<[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Allan McRae
In reply to this post by Ali H. Caliskan
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
>
> }
>  

Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Dieter Plaetinck
In reply to this post by Ali H. Caliskan
According to

On Sat, 5 Sep 2009 16:40:40 +0200
"Ali H. Caliskan" <[hidden email]> 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
> <[hidden email]<daenyth%[hidden email]>
> > wrote:
>                                                                   bash only supports
> > On Sat, Sep 5, 2009 at 10:32, Ali H. Caliskan<[hidden email]>
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
In reply to this post by Allan McRae
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...
>
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Allan McRae
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

Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Xavier-3
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 :)
Reply | Threaded
Open this post in threaded view
|

Re: split packages documentation

Ali H. Caliskan
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 <[hidden email]> 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=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 :)
>