On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin 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.

makepkg may use subpackages as a new package name subpackages=(foo-dev foo-doc kmail kopete)

Aaron Griffin wrote:

On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin 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)

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 4:24 PM, Miklos Vajna wrote:

On Mon, Jun 16, 2008 at 11:32:35PM +0400, Sergej Pupykin 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

Aaron Griffin wrote:

On Mon, Jun 16, 2008 at 12:57 PM, Sergej Pupykin 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 :

On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin 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 (Роман Кирилич)

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/

On Sat, Jun 14, 2008 at 2:22 PM, Xavier 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

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.

Am Montag 16 Juni 2008 17:38:44 schrieb Xavier:

On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae 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