Aaron Griffin wrote:
> On 9/21/07, Xavier <[EMAIL PROTECTED]> wrote:
>> On Fri, Sep 21, 2007 at 03:52:41PM -0500, Aaron Griffin wrote:
>>>> There is a recent feature request about it, including a patch :
>>>> http://bugs.archlinux.org/task/7982
>>>>
>>>> And also a beginning of discussion on pacman-dev ML :
>>>> http://www.archlinux.org/pipermail/pacman-dev/2007-September/009380.html
>>>>
>>>> So it might be not totally hopeless.
>>> Yeah there's another FR with a similar patch. We have three ongoing
>>> systems and none of them.... feel quite right.
>>>
>>> More input is needed 8)
>> Oh right, so just for the record, the one I missed is :
>> http://bugs.archlinux.org/task/7144
>>
>> This one already has the links to the two other projects in its comments.
>> http://archlinux.org/pipermail/pacman-dev/2007-April/008171.html
>> http://bugs.archlinux.org/task/7982
>
> I find it awfully ironic that a discussion about splitting packages
> was split from another email thread 8)
>
> Anyway, good call, this is a great place to discuss this - way more
> mindshare than the pacman-dev list.
>
> Let me summarize here.
>
> One of the things we'd LOVE to do with PKGBUILDs is create the ability
> to build multiple packages from one PKGBUILD. That is, we could run
> make once, and create: foo, foo-libs, and foo-scripts all at the same
> time.
> In addition, we'd like to be able to do this a second way - that is,
> build 2 packages, bar-mysql and bar-postgres, with different configure
> flags via the same PKGBUILD.
this is simpler to implement and it will lead to my implementation idea
for the first one, so i'll describe this first.
We can have multiple build(){} functions (that's what they really are).
My idea would look like:
pkgname=bar
pkgver=ver
pkgrel=rel
...
...
build("mysql") {
#steps to build mysql version
}
build("postgres") {
#steps to build postgres version
}
This would result in two packages: bar-mysql-ver-rel.pkg.tar.gz and
bar-postgres-ver-rel.pkg.tar.gz
One key feature would be to make sure normal functions are supported
from the build sections so we could do:
all_dbs() {
}
build("mysql") {
./configure --enable-mysql
all_dbs
}
build("postgres") {
./configure --enable-postgres
all_dbs
}
This is simple to implement and keeps the PKGBUILDs simple to write...
which is why I like it (i.e. splitting based on build). Note that each
build function will have an optional local variable desc=, which if
given will provide the description for that particular build packaging.
To achieve the first (i.e. splitting based on arbitrary file
collections) the PKGBUILDs will have to be a bit more complicated. There
will have to be a definition of a files collection like a files(){}
section or something.
so I see a:
pkgname=foo
pkgver=ver
pkgrel=rel
build()
{
./configure
make
make DESTDIR=... install
files("docs") {
#will build foo-docs-ver-rel.pkg.tar.gz
}
files("libs") {
#will build foo-libs-ver-rel.pkg.tar.gz
}
#all the unpicked files will be put together here
#into a package named foo-ver-rel.pkg.tar.gz
}
build("mysql") {
files("docs") {
#will create a foo-mysql-docs-ver-rel.pkg.tar.gz
}
#all unspecified files here will be put together
# into foo-mysql-ver-rel.pkg.tar.gz
}
Note that both the build() and files() sections can have a local desc=
(or pkgdesc=?) that it can optionally inherit from its parent.
This is my first draft, which is actually gotten from writting too many
RPM spec files, not liking them, wishing they were more like PKGBUILDs
and wishing PKGBUILDs would pick one or two good things from them spec
files.
cheers,
Essien
>
> Both of these features would be REALLY great, but there's a problem.
> No one can think of a really clean way to do it.
>
> So here's where you all come in - make your suggestions. You don't
> need a patch, you don't need to code anything, I'd just like to see
> how you THINK it should work, or how you'd LIKE it to work.
> We can cover feasibility afterwards.
>
> Go!
>
> _______________________________________________
> arch mailing list
> arch@archlinux.org
> http://archlinux.org/mailman/listinfo/arch
>
_______________________________________________
arch mailing list
arch@archlinux.org
http://archlinux.org/mailman/listinfo/arch
