Eric Bélanger wrote:
On Sun, Aug 9, 2009 at 10:33 PM, Allan McRae<allan@archlinux.org> wrote:
Eric Bélanger wrote:
On Sun, Aug 9, 2009 at 10:08 PM, Allan McRae<allan@archlinux.org> wrote:
Eric Bélanger wrote:
On Fri, Aug 7, 2009 at 2:19 AM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
Hi,
Here (inline and attached) are a couple of patches for makechrootpkg.
Here's a second patch. It fixes the copying of the package from the chroot when the pkgver or pkgrel are different (e.g. device-mapper & lvm2) :
Be careful there.... man PKGBUILD:
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.
So overriding pkgver and pkgrel may not work as expected.
Allan
Thanks for the warning, I wasn't aware about that. From the package's name and the .PKGINFO it seems to work, at least for different pkgver. However, I haven't tested the packages yet.
My suspicion is that it will work when the package with the different pkgver/pkgrel is last. makepkg just does not revert those variables after exiting the package function. Are there other use cases like this? That functionality could be added...
Allan
Actually I used it the other way around:
pkgname=('lvm2' 'device-mapper')
makepkg uses the order specified in pkgname not the order of the package_*() functions. So in this case you are fine.
In my knowledge, only lvm2 and device-mapper use different pkgver. But it might be usefull to be able to change these variables too, especially pkgrel. This will let us fix and upload only the affected packages. Otherwise, if we change the pkgrel of a PKGBUILD, we need to uploads and force the users to update all the packages that are built with that PKGBUILD even if they aren't affected by the fix.
Adding this would be quite easy. I had never found a use case for different pkgvers until now so ad never considered it. No idea why I had not considered pkgrels before. Allan