[pacman-dev] Splitting packages in makepkg
NOTE: This is a discussion about the technical implementation of the ability to build split packages in makepkg. DO NOT reply if all you want to say is splitting packages is a bad thing. Just because makepkg can split packages does not mean Arch will start splitting everything up into binary/header packages. I can say with great certainty that that will never happen. I was going to wait until 3.2 was out the door to start implementing the ability to split packages but there has been enough activity on the bug tracker lately that I thought this discussion would be timely. There have been several proposals for building split packages with makepkg. See: http://bugs.archlinux.org/task/7144 http://bugs.archlinux.org/task/7982 http://bugs.archlinux.org/task/8187 The question is how best to implement this. I can not see any other way than having a "split" array listing the names of the split components, so the need for this is almost a given. With input from the bug reports, I see two possible ways to implement this (in the PKGBUILD): 1) The KDEMod style (FS#7982), where each package has its own install function. e.g. base_install() { # do install stuff } gui_install() { # override pkgname etc # do install stuff } 2) A "package" function with a case statement. e.g. package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac } I am kind of torn here... I like the idea of having a single function but the syntax is slightly more complex. Although the multi function version is already in use, that should not be a limiting factor - we should be striving for technical elegance rather than accepting the current situation. The second point I would like to bring up is based on the suggestion in FS#8187. In it I suggested having separate subdirectories where each sub-package is installed into. This would be a benefit because it would not require the clearing of the pkg directory after each sub-package install as in the current KDEmod implementation. I see this would be a definite help when bugfixing a PKGBUILD as you can easily browse the installed files. It would also mean that we could keep the repackage option working. This could be implemented with either method by setting the pkgdir variable before calling whichever package function is chosen. But it would require the forcing of the use of $pkgdir rather than $startdir/pkg as that would fail. So people, what are you opinions on the ideas above? These are just the choices I can currently see so don't feel limited to only commenting on them. At this stage I would not worry about the actual naming scheme of functions etc, just the implementation. So please discuss (after going back and reading the top paragraph...). Allan
This is purely FWIW and I am *not* suggesting it be considered as the canonical way to provide split packages. It provides a test case for one approach that I have been using for months without requiring any patches to makepkg. Probably best demonstrated as a psuedo example... # cat PKGBUILD pkgname=qt-copy pkgver=4.4.0 ... etc build() { # regular main package build instructions build_doc build_dev } build_doc() { mv $pkgdir $pkgdir.orig && mkdir $pkgdir || return 1 mkdir -p $pkgdir/{usr/bin,usr/share/doc} mv $pkgdir.orig/usr/share/doc/* $pkgdir/usr/share/doc cd $startdir makepkg --asroot -R -p PKGBUILD.doc rm -rf $pkgdir mv $pkgdir.orig $pkgdir cd $srcdir/$pkgname-$pkgver } build_dev() { mv $pkgdir $pkgdir.orig && mkdir $pkgdir || return 1 mkdir -p $pkgdir/{usr/bin,usr/include} mv $pkgdir.orig/usr/include/* $pkgdir/usr/include # lazy mv $pkgdir.orig/usr/bin/* $pkgdir/usr/bin # mv all bins to dev mv $pkgdir/usr/bin/qtconfig $pkgdir.orig/usr/bin # mv qtconfig back mv $pkgdir/usr/bin/qdbus $pkgdir.orig/usr/bin # mv qdbus back cd $startdir makepkg --asroot -R -p PKGBUILD.dev rm -rf $pkgdir mv $pkgdir.orig $pkgdir cd $srcdir/$pkgname-$pkgver } ------------------------------ # cat PKGBUILD.doc pkgname=qt-copy-doc pkgver=4.4.0 pkgrel=$(date +%Y%m%d) pkgdesc="The Qt Gui Toolkit Documentation" url="http://www.trolltech.com/products/qt" arch=(any) source=($pkgname-$pkgver.tar.gz) license=(GPL) ------------------------------ # cat PKGBUILD.dev pkgname=qt-copy-dev pkgver=4.4.0 pkgrel=$(date +%Y%m%d) pkgdesc="The Qt Gui Toolkit Development Files" url="http://www.trolltech.com/products/qt" arch=(i686 x86_64) source=($pkgname-$pkgver.tar.gz) license=(GPL) --markc
Hi, I like following idea: PKGBUILD ------------------ pkgname=foobar pkgver=1.0 pkgrel=1 subpackages=(dev doc) .... build() { ..... make DESTDIR=$startdir/pkg install ... make DESTDIR=$startdir/pkg-dev install ... make DESTDIR=$startdir/pkg-doc install } --------------- According to subpackages array makepkg creates 3 dirs: - $startdir/pkg (as usually) - $startdir/pkg-dev - $startdir/pkg-doc PKGBUILDs build function install all stuff into them And then, makepkg creates 3 packages: $pkgname-...pkg.tar.gz $pkgname-dev-...pkg.tar.gz $pkgname-doc-...pkg.tar.gz
On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
Hi,
I like following idea:
PKGBUILD ------------------ pkgname=foobar pkgver=1.0 pkgrel=1 subpackages=(dev doc)
....
build() {
.....
make DESTDIR=$startdir/pkg install ... make DESTDIR=$startdir/pkg-dev install ... make DESTDIR=$startdir/pkg-doc install } ---------------
According to subpackages array makepkg creates 3 dirs: - $startdir/pkg (as usually) - $startdir/pkg-dev - $startdir/pkg-doc
PKGBUILDs build function install all stuff into them
And then, makepkg creates 3 packages:
$pkgname-...pkg.tar.gz $pkgname-dev-...pkg.tar.gz $pkgname-doc-...pkg.tar.gz
FTR I like this idea too. Just setup some way to use $pkgdir/foo/ instead of $pkgdir (that's what the subpackages=() array does in the above example), and then the rest is free-form. It's the simplest IMO.
On Mon 2008-06-16 10:56, Aaron Griffin wrote:
On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
Hi,
I like following idea:
PKGBUILD ------------------ pkgname=foobar pkgver=1.0 pkgrel=1 subpackages=(dev doc)
....
build() {
.....
make DESTDIR=$startdir/pkg install ... make DESTDIR=$startdir/pkg-dev install ... make DESTDIR=$startdir/pkg-doc install } ---------------
According to subpackages array makepkg creates 3 dirs: - $startdir/pkg (as usually) - $startdir/pkg-dev - $startdir/pkg-doc
PKGBUILDs build function install all stuff into them
And then, makepkg creates 3 packages:
$pkgname-...pkg.tar.gz $pkgname-dev-...pkg.tar.gz $pkgname-doc-...pkg.tar.gz
FTR I like this idea too. Just setup some way to use $pkgdir/foo/ instead of $pkgdir (that's what the subpackages=() array does in the above example), and then the rest is free-form. It's the simplest IMO.
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful. Just my 2 eurocents :) -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful.
makepkg may use subpackages as a new package name subpackages=(foo-dev foo-doc kmail kopete)
On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful.
makepkg may use subpackages as a new package name
subpackages=(foo-dev foo-doc kmail kopete)
Exactly what I was going to say - it's all hypothetical. We could use $pkgdir/full-package-name/* for a subpackage "full-package-name"
Aaron Griffin wrote:
On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin<pupykin.s@gmail.com> wrote:
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful. makepkg may use subpackages as a new package name
subpackages=(foo-dev foo-doc kmail kopete)
Exactly what I was going to say - it's all hypothetical. We could use $pkgdir/full-package-name/* for a subpackage "full-package-name"
Does that answer the second concern about pkgdesc? There are several other variables that could change as well (backup, group, etc)
Does that answer the second concern about pkgdesc? There are several other variables that could change as well (backup, group, etc)
We may use single backup. I do not think that the same file should be backuped in one package and should not be in another. More over it means these are conflicting packages splitted from one. about desc and group: subpackages=(dev doc) pkgdesc = "qweqwe" pkgdesc_dev="asdasd" pkgdesc_doc="zxczxc" ... groups=() groups_dev=() groups_doc=() ... may be replace subpackages with pkgname=(foo foo-dev foo-doc) ?
pkgdesc_dev="asdasd" pkgdesc_doc="zxczxc" groups_dev=() groups_doc=()
are not mandatory of course. pkgdesc and groups used if these vars are not set.
On Mon, Jun 16, 2008 at 11:32:35PM +0400, Sergej Pupykin <pupykin.s@gmail.com> wrote:
pkgdesc = "qweqwe"
^ this won't work in sh
pkgdesc_dev="asdasd" pkgdesc_doc="zxczxc" ... groups=() groups_dev=() groups_doc=() ...
and this is where you make it impossible to name a subpkg 'kopete', right? how would that handle the case when for example openoffice.org-i18n-de is split from openoffice.org? (given that the implementation we have in pacman-g2 was already flamed off here, iirc - i don't want to hype it here, but that one deals with such a problem properly.)
On Mon, Jun 16, 2008 at 4:24 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Mon, Jun 16, 2008 at 11:32:35PM +0400, Sergej Pupykin <pupykin.s@gmail.com> wrote:
pkgdesc = "qweqwe"
^ this won't work in sh
pkgdesc_dev="asdasd" pkgdesc_doc="zxczxc" ... groups=() groups_dev=() groups_doc=() ...
and this is where you make it impossible to name a subpkg 'kopete', right?
how would that handle the case when for example openoffice.org-i18n-de is split from openoffice.org?
(given that the implementation we have in pacman-g2 was already flamed off here, iirc - i don't want to hype it here, but that one deals with such a problem properly.)
Can you possibly give us an overview of how it works? I think it would be quite relevant to this discussion as it is actually a system that is used, rather than a bunch of "well this might work" scenarios. -Dan
On Mon, Jun 16, 2008 at 04:31:11PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
and this is where you make it impossible to name a subpkg 'kopete', right?
how would that handle the case when for example openoffice.org-i18n-de is split from openoffice.org?
(given that the implementation we have in pacman-g2 was already flamed off here, iirc - i don't want to hype it here, but that one deals with such a problem properly.)
Can you possibly give us an overview of how it works? I think it would be quite relevant to this discussion as it is actually a system that is used, rather than a bunch of "well this might work" scenarios.
http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=blob;f=doc/Fru... -> '=== Package splitting' basically we have a subpkgs() array which defines the subpackages, and we have subfoo variables for other foo variables, like: pkgname=libfoo groups=('foo' 'bar') pkgname=foo-doc groups=('baz' 'blah') becomes subpkgs=('libfoo' "$pkgname-doc") groups=('foo bar' 'baz blah') the main package's files are still under $startdir/pkg, but libfoo is under $startdir/pkg.libfoo, foo-doc is under $startdir/pkg.foo-doc, etc. there is also a macro called Fsplit that moves a files/directories from $startdir/pkg to a $startdir/pkg.foo dir, like: Fsplit subpkgname usr/share/ but of course it can be done manually using mkdir and mv. here is a more complex example when there are a lot of subpackages: http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-stable.git;a=blob;f... probably the biggest problem with it (since every implementation has some problems) is that it can be a bit tricky to see for example what deps are set for a given subpackage if you have a lot of them. like this: http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-stable.git;a=blob;f... if you ask me what deps 'gcc-objc++' has, then i can't say the answer right now, i have to search a bit. and the big benefit (what rpm does not have) is that if you don't split a given file then it's included in the main package and it is not just dropped, like rpm does.
Aaron Griffin wrote:
On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful.
makepkg may use subpackages as a new package name
subpackages=(foo-dev foo-doc kmail kopete)
Exactly what I was going to say - it's all hypothetical. We could use $pkgdir/full-package-name/* for a subpackage "full-package-name"
Just another thought. Why do we even need the subpkg array. Why not: "pkgname=foo" for single packages and "pkgname=('foo' 'foo-bar' 'foo-doc')" for split packages? I would have to check that you can do that in bash...
Aaron Griffin wrote:
On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
I see a downside in the proposed scheme: you can not create a package without the $pkgname- suffix, e.g. you can't create the "kopete" or "kmail" package from "kdenetwork". Moreover, you can't change the pkgdesc for each sub-package, which can be useful.
makepkg may use subpackages as a new package name
subpackages=(foo-dev foo-doc kmail kopete)
Exactly what I was going to say - it's all hypothetical. We could use $pkgdir/full-package-name/* for a subpackage "full-package-name"
Just another thought. Why do we even need the subpkg array. Why not: "pkgname=foo" for single packages and "pkgname=('foo' 'foo-bar' 'foo-doc')" for split packages? I would have to check that you can do that in bash...
2008/6/16 Aaron Griffin <aaronmgriffin@gmail.com>:
On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
Hi,
I like following idea:
PKGBUILD ------------------ pkgname=foobar pkgver=1.0 pkgrel=1 subpackages=(dev doc)
....
build() {
.....
make DESTDIR=$startdir/pkg install ... make DESTDIR=$startdir/pkg-dev install ... make DESTDIR=$startdir/pkg-doc install } ---------------
According to subpackages array makepkg creates 3 dirs: - $startdir/pkg (as usually) - $startdir/pkg-dev - $startdir/pkg-doc
PKGBUILDs build function install all stuff into them
And then, makepkg creates 3 packages:
$pkgname-...pkg.tar.gz $pkgname-dev-...pkg.tar.gz $pkgname-doc-...pkg.tar.gz
FTR I like this idea too. Just setup some way to use $pkgdir/foo/ instead of $pkgdir (that's what the subpackages=() array does in the above example), and then the rest is free-form. It's the simplest IMO.
It's my favourite too. -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2008/6/16 Aaron Griffin <aaronmgriffin@gmail.com>:
On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
Hi,
I like following idea:
PKGBUILD ------------------ pkgname=foobar pkgver=1.0 pkgrel=1 subpackages=(dev doc)
....
build() {
.....
make DESTDIR=$startdir/pkg install ... make DESTDIR=$startdir/pkg-dev install ... make DESTDIR=$startdir/pkg-doc install } ---------------
According to subpackages array makepkg creates 3 dirs: - $startdir/pkg (as usually) - $startdir/pkg-dev - $startdir/pkg-doc
PKGBUILDs build function install all stuff into them
And then, makepkg creates 3 packages:
$pkgname-...pkg.tar.gz $pkgname-dev-...pkg.tar.gz $pkgname-doc-...pkg.tar.gz
FTR I like this idea too. Just setup some way to use $pkgdir/foo/ instead of $pkgdir (that's what the subpackages=() array does in the above example), and then the rest is free-form. It's the simplest IMO.
It's my favourite too.
This is pretty much what I suggested in one of the bug reports about this. But, the problems I now have with this method are: 1) where do you define the different pkgdesc for each package 2) what if there is no obvious "base" package?
Ooor... Define pkgname-common-sources/PKGBUILD's source, md5sums, etc. and install them in /usr/share/pkgname/common-sources Then in each subpackage, pkgname-subpkgs/PKGBUILD contains depends=(... pkgname-common-sources) You can ln -sf /usr/share/pkgname/common-sources "$srcdir/$pkgname" if you wish. -- Geoffroy Carrier http://gcarrier.koon.fr/
Allan McRae wrote:
I was going to wait until 3.2 was out the door to start implementing the ability to split packages but there has been enough activity on the bug tracker lately that I thought this discussion would be timely.
There have been several proposals for building split packages with makepkg. See: http://bugs.archlinux.org/task/7144 http://bugs.archlinux.org/task/7982 http://bugs.archlinux.org/task/8187
The question is how best to implement this. I can not see any other way than having a "split" array listing the names of the split components, so the need for this is almost a given.
With input from the bug reports, I see two possible ways to implement this (in the PKGBUILD):
1) The KDEMod style (FS#7982), where each package has its own install function. e.g.
base_install() { # do install stuff }
gui_install() { # override pkgname etc # do install stuff }
2) A "package" function with a case statement. e.g.
package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac }
I am kind of torn here... I like the idea of having a single function but the syntax is slightly more complex. Although the multi function version is already in use, that should not be a limiting factor - we should be striving for technical elegance rather than accepting the current situation.
The multi function way looks nicer to me.
The second point I would like to bring up is based on the suggestion in FS#8187. In it I suggested having separate subdirectories where each sub-package is installed into. This would be a benefit because it would not require the clearing of the pkg directory after each sub-package install as in the current KDEmod implementation. I see this would be a definite help when bugfixing a PKGBUILD as you can easily browse the installed files. It would also mean that we could keep the repackage option working.
This could be implemented with either method by setting the pkgdir variable before calling whichever package function is chosen. But it would require the forcing of the use of $pkgdir rather than $startdir/pkg as that would fail.
It seems like we already have a working patch for the kdemod / multifunction way, though it apparently doesn't use separate subdir. So maybe you could try to apply your idea on it? $pkgdir will already be the recommended way for 3.2 (Dan commented it that way in the man page at least ;) ). With your suggestion, its usage would only be forced in the case of new PKGBUILDs that use the split feature, and not to all existing PKGBUILDs, so I think that's alright.
On Sat, Jun 14, 2008 at 2:22 PM, Xavier <shiningxc@gmail.com> wrote:
Allan McRae wrote:
I was going to wait until 3.2 was out the door to start implementing the ability to split packages but there has been enough activity on the bug tracker lately that I thought this discussion would be timely.
There have been several proposals for building split packages with makepkg. See: http://bugs.archlinux.org/task/7144 http://bugs.archlinux.org/task/7982 http://bugs.archlinux.org/task/8187
The question is how best to implement this. I can not see any other way than having a "split" array listing the names of the split components, so the need for this is almost a given.
With input from the bug reports, I see two possible ways to implement this (in the PKGBUILD):
1) The KDEMod style (FS#7982), where each package has its own install function. e.g.
base_install() { # do install stuff }
gui_install() { # override pkgname etc # do install stuff }
2) A "package" function with a case statement. e.g.
package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac }
I am kind of torn here... I like the idea of having a single function but the syntax is slightly more complex. Although the multi function version is already in use, that should not be a limiting factor - we should be striving for technical elegance rather than accepting the current situation.
The multi function way looks nicer to me.
The second point I would like to bring up is based on the suggestion in FS#8187. In it I suggested having separate subdirectories where each sub-package is installed into. This would be a benefit because it would not require the clearing of the pkg directory after each sub-package install as in the current KDEmod implementation. I see this would be a definite help when bugfixing a PKGBUILD as you can easily browse the installed files. It would also mean that we could keep the repackage option working.
This could be implemented with either method by setting the pkgdir variable before calling whichever package function is chosen. But it would require the forcing of the use of $pkgdir rather than $startdir/pkg as that would fail.
It seems like we already have a working patch for the kdemod / multifunction way, though it apparently doesn't use separate subdir. So maybe you could try to apply your idea on it?
$pkgdir will already be the recommended way for 3.2 (Dan commented it that way in the man page at least ;) ). With your suggestion, its usage would only be forced in the case of new PKGBUILDs that use the split feature, and not to all existing PKGBUILDs, so I think that's alright.
Yeah, I definitely made those comments in the manpage that way on purpose- this will allow us much greater flexibility in the future, especially for things like building all packages in a tmpfs or something. The only reason I can think you would still want to use a $startdir variable is for something like VCS packages where you store the most recent checkout somewhere for future use. With that said, I've been pretty quiet on this whole split/multiple packages issue simply because I'm not sure what is best, and I'm not the one that would use it. A few thoughts of mine: 1. I've had this so-called fake_install() branch around for a while locally, and I've always thought it was a decent idea: http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=5e955fc9bd5... The naming of the fake_install() function could change, but what this allows is for the build and install steps of packaging to be seperated, and only the install step gets run under fakeroot. This was the final step towards doing as little work in fakeroot as possible, but I got cold feet on merging it because it would add some possible complexity to PKGBUILDs. However, I think the idea is quite sound and having a build() function and an install() function in a PKGBUILD would not be too much clutter in my opinion. 2. The above mentioned patch would really play into what worked as far as split packages. I think having the option of one or multiple build functions, followed by multiple install functions, would be beneficial. Here is what I envision, of course I haven't assessed the practicality, and I can already tell I may be thinking too complex after seeing a <30 line patch doing some sort of split. options=('splitpkg') (not sure yet where to stick the names/versions of other sub packages) if build() is present, call build() else if build_pkg1() is present, call that, then build_pkg2(), etc. Each of these would get passed a unique srcdir? call install_pkg1(), install_pkg2(), etc, each with their own unique pkgdir (e.g. don't share a common pkg/ directory). Blah. I don't know. But that patch from item #1 is more important to me than the rest, so keep that in mind when I am looking at any split package patches. -Dan
On 2008-06-15, Dan McGee wrote:
The only reason I can think you would still want to use a $startdir variable is for something like VCS packages where you store the most recent checkout somewhere for future use.
Just on this particular point I have about 20Gb of VCS source inside $SRCDEST and there is no way I want to have that much persistent stuff spread out in 100s of separate source package directories. Especially when one significant component is KDE trunk which only requires a single svn up for what results in a couple of dozen separate package builds. ATM I use a build wrapper script that pulls *all* the VCS into $SRCDEST in a single operation then the next step is to create the tarballs also, obviously, in $SRCDEST then most of my PKGBUILDs just refer to.. sources=($pkgname-$pkgver.tar.bz2). If there could be something like a $vcsdir var, that defaults to $startdir, in front of all the paths in the VCS management sections of makepkg then that would be excellent. --markc
Dan McGee wrote:
<snip> 1. I've had this so-called fake_install() branch around for a while locally, and I've always thought it was a decent idea: http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=5e955fc9bd5... The naming of the fake_install() function could change, but what this allows is for the build and install steps of packaging to be seperated, and only the install step gets run under fakeroot. This was the final step towards doing as little work in fakeroot as possible, but I got cold feet on merging it because it would add some possible complexity to PKGBUILDs. However, I think the idea is quite sound and having a build() function and an install() function in a PKGBUILD would not be too much clutter in my opinion.
This looks interesting. And it actually gives me some perspective on which is the best way to implement package splitting. This would make the standard non-split pkgbuild looked like: build() { } package() { } So with a split package, the package part could be: #1) KDEmod style package_base() { #do base install } package_gui() { #override pkgname etc # do gui install } #2) Modified KDEmod style package() { # do base install } package_gui() { #override pkgname etc # do gui install } #3) case statement way package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac } Now think about how we keep backwards compatibility with old PKGBUILDs that don't have a package function of any variety. Without split packages, we have to test if the package() function is present to decide whether or not the build() segment is run in fakeroot. This is compatible with splitting methods #2 and #3 where there is a package function but not with #1 which would require an additional check for the definition of a "split" array. Option #2 also suffers from the problem that there may not be a main part to package so it may not be obvious what should be in the package() function. Thus, I think option #2 can be excluded from here on. Option #1 is essentially what the KDEmod team have done and would only require an additional test for the "split" array to know what to use fakeroot on. However, you end up with as many package functions as there are sub-packages which itself makes the PKGBUILD less clear. Option #3 is my personal favorite as you still only have two functions - build and package. Admittedly the package function is slightly more complex when building a split package but if you wanted it simple, you would be using two PKGBUILDs instead of one. Still, I find it the cleaner of the options but I may be fighting a losing campaign here given option #1 is "in the wild"... In the end, I think splitting packages is a nice feature but I doubt I will use it frequently. So the decision should be weighted by those who would. Now the KDEmod team chose option #1. My question is: Was that because it was the best way or was it just because it worked? I think it would be good to combine the whole split packages, multiple package directories, minimal fake install ideas but I am still trying to decide what the best way to do this is.
On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan@hotmail.com> wrote:
So with a split package, the package part could be:
#1) KDEmod style
package_base() { #do base install }
package_gui() { #override pkgname etc # do gui install }
#2) Modified KDEmod style
package() { # do base install }
package_gui() { #override pkgname etc # do gui install }
#3) case statement way
package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac }
Now think about how we keep backwards compatibility with old PKGBUILDs that don't have a package function of any variety. Without split packages, we have to test if the package() function is present to decide whether or not the build() segment is run in fakeroot. This is compatible with splitting methods #2 and #3 where there is a package function but not with #1 which would require an additional check for the definition of a "split" array. Option #2 also suffers from the problem that there may not be a main part to package so it may not be obvious what should be in the package() function. Thus, I think option #2 can be excluded from here on.
Option #1 is essentially what the KDEmod team have done and would only require an additional test for the "split" array to know what to use fakeroot on. However, you end up with as many package functions as there are sub-packages which itself makes the PKGBUILD less clear.
Option #3 is my personal favorite as you still only have two functions - build and package. Admittedly the package function is slightly more complex when building a split package but if you wanted it simple, you would be using two PKGBUILDs instead of one. Still, I find it the cleaner of the options but I may be fighting a losing campaign here given option #1 is "in the wild"...
In the end, I think splitting packages is a nice feature but I doubt I will use it frequently. So the decision should be weighted by those who would. Now the KDEmod team chose option #1. My question is: Was that because it was the best way or was it just because it worked? I think it would be good to combine the whole split packages, multiple package directories, minimal fake install ideas but I am still trying to decide what the best way to do this is.
What bothers me here is that the only question is asked directly to the kdemod team. I am not sure they all follow this mailing list. Maybe you should just ask them privately (have a look at the people who contributed to that bug report). But personally, I find that option #1 looks nicer ;)
Am Montag 16 Juni 2008 17:38:44 schrieb Xavier:
On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan@hotmail.com> wrote:
So with a split package, the package part could be:
#1) KDEmod style
package_base() { #do base install }
package_gui() { #override pkgname etc # do gui install }
#2) Modified KDEmod style
package() { # do base install }
package_gui() { #override pkgname etc # do gui install }
#3) case statement way
package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac }
... Now the KDEmod team chose option #1. My question is: Was that because it was the best way or was it just because it worked? ...
What bothers me here is that the only question is asked directly to the kdemod team. I am not sure they all follow this mailing list. Maybe you should just ask them privately (have a look at the people who contributed to that bug report). But personally, I find that option #1 looks nicer ;)
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Hi there, i just registered at this ML - my first ML experience ever, so please be nice to me :) To answer Allans question about "our way" of building splitted packages... When Dunkelstern and me realized that we cannot maintain over 200 splitted packages with the standard arch makepkg, i sat down and created a first prototype of a PKGBUILD for splitted packages. It was basically the same as what you can see now in our PKGBUILDs, except the splitinstall array - i just created multiple install functions, every one of these with an additional array that holds the directories to "make install" in... Dunkelstern took that idea, added the splitinstall array, created a patch for makepkg, and after some testing and additional patching we had we basically needed... For us, it was (and still is) the best way to create splitted packages without a lot of hassle and/or applying big patches to makepkg (which also have to be maintained, we didnt expect that this will be a topic here) - and this solution works good for us since we created this stuff, and has decreased our workload a lot... About the other 2 solutions Allan wrote about: #2 looks almost the same like our stuff, except that is seems to implement the "base package" stuff statically... We did not want that because with our solution we have no limits and can split stuff like we want... (My english is not that good, maybe i am sounding a bit too generic here)... Its like that: If you already have the possibility to create a "base package", why do you need to create an extra (static) package() function? Our solution already does that by itself, and you can give the install functions any name you want... #3 Seems to move more of the "splitting logic" into the PKGBUILD itself, which isnt so nice imho... Also the case stuff decreases readability in my opinion... With our solution we have just one additional for-loop and an array of the directories to make install in, which is also very clear and readable... So, to come to an end here: I definitely see a some room for improvements regarding our solution, but i also like the flexibility and freedom of it, as you can define nearly everything as you like... And in case you are asking yourself what could be improved: - pkg/ gets deleted after the installation of every sub-package, so re-packaging does not work - the "-i" option to install packages directly after the build does not work with splitted packages (i am currently working on a patch for problem #2) These are the only things that could be improved from my point of view... We are using this stuff since a long time now, and i can say that we are very happy with this solution :) Greetings Jan (funkyou) PS: Again, sorry for my poor english
participants (12)
-
Aaron Griffin
-
Alessio Bolognino
-
Allan McRae
-
Allan McRae
-
Dan McGee
-
Geoffroy Carrier
-
Jan Mette
-
Mark Constable
-
Miklos Vajna
-
Roman Kyrylych
-
Sergej Pupykin
-
Xavier