[pacman-dev] Splitting packages with makepkg
Hi all, Now that pacman 3.2 is out the door and the initial bug fixes appear done, I am going to work on adding the package splitting feature to makepkg. So the time has come for some input on the prototype PKGBUILD for splitting packages again. We discussed this a couple of months ago on this list (http://archlinux.org/pipermail/pacman-dev/2008-June/012123.html). From that discussion I have come up with a PKGBUILD prototype which I like (prototype 1 at http://dev.archlinux.org/~allan/splitpkg.html) which is inspired by the KDEMod method but has a few significant differences. This is a call for comments or other prototypes to implement this function. Some "rules" to help us all with this: 1) If submitting a new idea, attach a complete prototype (based on the one distributed with pacman) so we can see all details of how the packaging is done. Add notes if necessary. Point out the advantages of your method. 2) Note that the ability to separate the building and packaging stages of a PKGBUILD is going to be added to makepkg so that fakeroot is used for the smallest amount of time. Any new prototype should account for this. 3) No comments about how splitting packages is bad and this will be the ruin of Arch. Arch does not favor package splitting in its main repos and this will not change that fact. Allan
On Thu, Aug 14, 2008 at 4:29 PM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
Now that pacman 3.2 is out the door and the initial bug fixes appear done, I am going to work on adding the package splitting feature to makepkg.
So the time has come for some input on the prototype PKGBUILD for splitting packages again. We discussed this a couple of months ago on this list (http://archlinux.org/pipermail/pacman-dev/2008-June/012123.html). From that discussion I have come up with a PKGBUILD prototype which I like (prototype 1 at http://dev.archlinux.org/~allan/splitpkg.html) which is inspired by the KDEMod method but has a few significant differences.
I had a quick look at the prototype and it looked fine. Then I had a quick look at the comments I made in the previous thread, and all the issues I discussed were dealt with: 1) a way to override the package variables 2) a style close enough to the one already in use by kdemod, that is multi functions (it was my favorite style anyway) 3) usage of subdirs to allow the possibility of -R / repackage So it looks great to me.
Am Fri, 15 Aug 2008 00:29:36 +1000 schrieb Allan McRae <allan@archlinux.org>:
Hi all,
Now that pacman 3.2 is out the door and the initial bug fixes appear done, I am going to work on adding the package splitting feature to makepkg.
So the time has come for some input on the prototype PKGBUILD for splitting packages again. We discussed this a couple of months ago on this list (http://archlinux.org/pipermail/pacman-dev/2008-June/012123.html). From that discussion I have come up with a PKGBUILD prototype which I like (prototype 1 at http://dev.archlinux.org/~allan/splitpkg.html) which is inspired by the KDEMod method but has a few significant differences.
Silly things first, you're missing a 2 in your pkgname array. Now my (maybe) more useful comments: This looks very much like the PKGBUILD I already had in my head after reading the other threads and thinking about splitting packages. While thinking I became unsure about two things: 1) Is one build function enough? In an older thread someone (Aaron I think) talked about building packages with different configurations from one packagebuild. I am not sure you can do this with one build function. What you could do, is using the package functions to do this, this would go against the "minimal fakeroot usage" thing, but is probably sufficent for something rather uncommon. An alternative would be, checking for build_pkgname functions and calling them if they are defined. 2) This is a bit implementation specific, but I think it is important. Is there any way, except parsing the PKGBUILD file, to get the contents of all depends arrays, to check the depends before building the package? If not, overriding depends could be problematic.
On Thu, Aug 14, 2008 at 9:45 PM, Henning Garus <henning.garus@googlemail.com> wrote:
1) Is one build function enough? In an older thread someone (Aaron I think) talked about building packages with different configurations from one packagebuild. I am not sure you can do this with one build function. What you could do, is using the package functions to do this, this would go against the "minimal fakeroot usage" thing, but is probably sufficent for something rather uncommon. An alternative would be, checking for build_pkgname functions and calling them if they are defined.
In my opinion, it is "sufficient for something rather uncommon". And in the normal usage with one build function and several package functions, the fakeroot usage would already be less than now since the build function does not need it. But I find the build_pkgname idea decent, so no strong opinion on my part. And anyway, it will be up to the people implementing it :)
2) This is a bit implementation specific, but I think it is important. Is there any way, except parsing the PKGBUILD file, to get the contents of all depends arrays, to check the depends before building the package? If not, overriding depends could be problematic.
That is important indeed and I never thought about it. But finally it looks fine. You have the main depends array that is used for the build() function, which is checked before building the package. So there, you put all dependencies required for building. And then, each package is free to override it, probably for only having a subset of the original depends array.
Am Thu, 14 Aug 2008 22:04:36 +0200 schrieb Xavier <shiningxc@gmail.com>:
That is important indeed and I never thought about it. But finally it looks fine. You have the main depends array that is used for the build() function, which is checked before building the package. So there, you put all dependencies required for building. And then, each package is free to override it, probably for only having a subset of the original depends array.
Maybe I'm thinking too much :P . A packager who even considers to build split packages should be able to understand something simple like: Define all your depends outside the functions, override if needed. So documenting it could be sufficient. It just seems a little bit "dirty". However, as long as I can't come up with a better solution...
Henning Garus wrote:
Silly things first, you're missing a 2 in your pkgname array.
I had fixed that then didn't save before I uploaded it...
Now my (maybe) more useful comments:
This looks very much like the PKGBUILD I already had in my head after reading the other threads and thinking about splitting packages. While thinking I became unsure about two things:
1) Is one build function enough? In an older thread someone (Aaron I think) talked about building packages with different configurations from one packagebuild. I am not sure you can do this with one build function. What you could do, is using the package functions to do this, this would go against the "minimal fakeroot usage" thing, but is probably sufficent for something rather uncommon. An alternative would be, checking for build_pkgname functions and calling them if they are defined.
Two build functions sounds like it would require two install functions (as each package would probably have to add a conflict to the other) which is really two PKGBUILDs. I am not against adding this at the same time but I would need to be convinced with a (useful) real world example here.
2) This is a bit implementation specific, but I think it is important. Is there any way, except parsing the PKGBUILD file, to get the contents of all depends arrays, to check the depends before building the package? If not, overriding depends could be problematic.
As Xavier pointed out, I think that there would a big use of makedepends and overriding of depends in the individual package functions. In fact, I am not sure what the depends array at the top of the PKGBUILD actually means with split packages... Allan
participants (3)
-
Allan McRae
-
Henning Garus
-
Xavier