Re: [Qemu-devel] Is there a way to package QEMU binaries?

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Xu <peterx@redhat.com> writes:

> On Thu, Jun 14, 2018 at 11:50:23AM +0100, Peter Maydell wrote:
>> On 14 June 2018 at 09:14, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> > On Thu, Jun 14, 2018 at 10:55:21AM +0800, Peter Xu wrote:
>> >> Then is there an easy way to port the specfile and tools to QEMU
>> >> repository so that we can pack that even with a git tree?
>>
>> > Well if we want to have a RPM spec file for QEMU distributed with upstream
>> > QEMU, then I think it would be better todo what libvirt does[2], and simply
>> > have the real Fedora  specfile kept in QEMU git [3].
>>
>> I would prefer not to. I think packaging is a job for downstream
>> distributors, and having our own (probably under-maintained)
>> version of the packaging infrastructure in upstream git just
>> makes things awkward for downstream, and requires us to make
>> choices about which distros we think "important" enough to
>> provide packaging for...
>
> AFAIU that's not a problem; we can just provide more ways to package
> the system gradually, just like what Linux did:
>
> Kernel packaging:
>   rpm-pkg             - Build both source and binary RPM kernel packages
>   binrpm-pkg          - Build only the binary kernel RPM package
>   deb-pkg             - Build both source and binary deb kernel packages
>   bindeb-pkg          - Build only the binary kernel deb package
>   snap-pkg            - Build only the binary kernel snap package (will connect to external hosts)
>   tar-pkg             - Build the kernel as an uncompressed tarball
>   targz-pkg           - Build the kernel as a gzip compressed tarball
>   tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
>   tarxz-pkg           - Build the kernel as a xz compressed tarball

I suspect the kernel is a special case as there aren't that many
dependencies or interactions to worry about. That said I think the make
install logic interfaces with some distro supplied hooks.

> But it seems that this package thing is not really that welcomed (and
> after all we have multiple specfiles here and there).  Then I think
> I'll just live with it now.

I could see an argument for hosting distro-agnostic packaging in the
QEMU source tree for things like snap or flatpak. However there is no
one uniform packaging approach for either deb or rpm based systems. They
all have their own rules and approaches to where things go that means
they are best served by the respective distributions.

>
> Regards,


--
Alex Bennée