Eric Bélanger wrote:
On Sun, Aug 9, 2009 at 10:33 PM, Allan McRae<[email protected]> wrote:
Eric Bélanger wrote:
On Sun, Aug 9, 2009 at 10:08 PM, Allan McRae<[email protected]> wrote:

Eric Bélanger wrote:

On Fri, Aug 7, 2009 at 2:19 AM, Eric Bélanger<[email protected]>
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




Reply via email to