[pve-devel] [PATCH ha-manager] Add make dsc target
Rhonda D'Vine
rhonda at proxmox.com
Mon Jan 7 15:14:21 CET 2019
Hi.
On 1/7/19 2:25 PM, Thomas Lamprecht wrote:
> On 1/7/19 1:51 PM, Rhonda D'Vine wrote:
>> Pull out the build dir creation into its own target, and add the "dsc"
>> target. Also get some static information from the packaging.
>>
>> Signed-off-by: Rhonda D'Vine <rhonda at proxmox.com>
>> ---
>> Makefile | 31 +++++++++++++++++++++----------
>> 1 file changed, 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 89fa8a4..9b2b7c0 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1,14 +1,16 @@
>> -VERSION=2.0
>> -PACKAGE=pve-ha-manager
>> +VERSION != dpkg-parsechangelog -Sversion | cut -d- -f1
>> +PACKAGE != dpkg-parsechangelog -Ssource
>> SIMPACKAGE=pve-ha-simulator
>> -PKGREL=6
>> +PKGREL != dpkg-parsechangelog -Sversion | cut -d- -f2
> 1. this has nothing to do with the dsc make-target addition
> 2. I'd like to keep this as is for now, the mix for hardcoded (simpackage) and
> computed looks a bit weird and I do not see a real advantage for simple
> versioning schemas as this is (in contrary to, e.g., the pve-edk2-firmware one)
> they may even get wrong if the versioning schema (for, e.g., a backport) or
> package name changes.
Okay, I can see the point with the mixed parts. Actually I realized
that there isn't even a need to define SIMPACKAGE because it's only used
in the lintian call - which actually should be based on the created
.changes file instead, and thus would pick up all binary packages
regardless. That would also be something that could get done across all
packages in the long run to reduce complexity and eliminate specific
differences between the packages.
> Further, a simple "make" invocation gives me a recursive package build loop,
> did you test this?
Yes I did, that puzzles me. But I now see that you are using -j8, my
build test host only got one CPU, so it didn't try to build DEB and
SIMDEB in parallel, and building DEB produced SIMDEB.
My bad, will clean that up to make it build on multithreaded build
systems too. What's interesting is: I didn't change that part. That
should have failed for you before already, without my patch. I don't see
how it would have affected that.
Thanks,
Rhonda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20190107/f0b8b8b1/attachment.sig>
More information about the pve-devel
mailing list