Re: [libvirt] [PATCH v2] maint: Switch to xz compressed PAX release archives
On 06/15/2016 11:22 AM, Daniel P. Berrange wrote:
On Wed, Jun 15, 2016 at 10:31:16AM -0400, Laine Stump wrote:
> On 06/15/2016 09:03 AM, Andrea Bolognani wrote:
>> This allows us to produce releases that are roughly a third in
>> size, have no limitation on path length, and are still readable
>> by all supported platforms.
>> ---
> I just want to point out that the tarfile is built every time you run "make
> rpm" (which I do quite a lot - I prefer installing rpms to the carnage
> created by make install), and this increases the time for make rpm on my
> system by 1min38sec. (jtomko may have something to say about that, since
> he's been interested in shaving fractions of a second off the build time in
> the last few days :-O)
>
> Am I going to need to carry a local patch to revert this so that I don't get
> *even more* bored waiting for builds to complete? Or is there a reasonable
> way to make it easily configurable with a switch to autogen? (even then I
> would still need a patch to the specfile, unless we could make it happen
> based on some environment setting).
You really shouldn't waste your time doing make rpm all the time IMHO.
./autogen.sh --system
make -j 12
sudo systemctl stop libvirtd.service
sudo ./daemon/libvirtd
will "just work(tm)" - its how I've done all libvirt development for
years.
Yeah, I used to do it that way, and at some point I switched to just
making the rpm and installing it. I don't even remember now why I did
that - it could have just been because I was testing on a different
machine from where I was building, or maybe I was rebooting a lot and
wanted my new libvirtd to be the one that came up at boot time. At the
time I switched, the penalty was small enough that it just became
automatic, but over the last year or so the build time (for make -j$LOTS
rpm) has slowly crept up to the point where it's now time to retrain my
muscle memory and use the in-tree libvirtd.
I suppose one downside of that is that make rpm failures won't be
noticed as quickly :-)