Packaging: Rationale for some split packages
I work on inclusion of Vdsm into Debian. I don't know what are the reasons for having separate `infra', `xmlrpc', `yajsonrpc', and `jsonrpc' packages. Could you please provide rationale for having each of those packages, separated from `vdsm' and `vdsm-python'? I need to put proper explanations into package descriptions so that the users know whether they should install/remove those packages or not. Thanks, Milan
On Thu, Jan 21, 2016 at 5:02 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I work on inclusion of Vdsm into Debian. I don't know what are the reasons for having separate `infra', `xmlrpc', `yajsonrpc', and `jsonrpc' packages.
- infra package contains infra related modules like zombiereaper, sygutils (core infra utils) - xmlrpc package contains xmlrpc binding code (optional and can be disabled in config.py) this package will be removed once we decide to drop xmlrpc - jsonrpc package contains jsonrpc binding code (optional and can be disabled in config.py) this package is required to process jsonrpc based rpc calls - yajsonrpc package contains stomp related server side code (required for rpc) - api package contains vdsm and gluster (optionally) schemas and code to process them used for rpc validation required by jsonrpc
Could you please provide rationale for having each of those packages, separated from `vdsm' and `vdsm-python'? I need to put proper explanations into package descriptions so that the users know whether they should install/remove those packages or not.
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Fri, Jan 22, 2016 at 11:28 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com> wrote:
On Thu, Jan 21, 2016 at 5:02 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I work on inclusion of Vdsm into Debian. I don't know what are the reasons for having separate `infra', `xmlrpc', `yajsonrpc', and `jsonrpc' packages.
- infra package contains infra related modules like zombiereaper, sygutils (core infra utils)
There is no technical reason to have this package, it should be merge into vdsm-python.
- xmlrpc package contains xmlrpc binding code (optional and can be disabled in config.py) this package will be removed once we decide to drop xmlrpc
Hopefully we can drop this after 4.0
- jsonrpc package contains jsonrpc binding code (optional and can be disabled in config.py) this package is required to process jsonrpc based rpc calls
This is not optional in 3.6, there is no reason to have it as separate package, should be merged into vdsm-python.
- yajsonrpc package contains stomp related server side code (required for rpc)
Same, no reason to have this as separate package, should be merge into vdsm-python
- api package contains vdsm and gluster (optionally) schemas and code to process them used for rpc validation required by jsonrpc
This package may be needed by vdsm clients, so it should be a separate package. We have too many packages, which make installation and upgrade harder for no reason. Lets simplify packaging for 4.0. We require the same version of all vdsm-xxx packages - upgrading only one package is not supported or tested. Nir
Could you please provide rationale for having each of those packages, separated from `vdsm' and `vdsm-python'? I need to put proper explanations into package descriptions so that the users know whether they should install/remove those packages or not.
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Thank you for clarification. So as for Debian, I'll create vdsm-api package (after 3.6) and I won't separate the other mentioned packages from vdsm-python.
If in debian we will have different set of rpms for vdsm, can you please also add section about how to build and install vdsm over debian in https://www.ovirt.org/Vdsm_Developers ? On Fri, Jan 22, 2016 at 3:34 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Thank you for clarification. So as for Debian, I'll create vdsm-api package (after 3.6) and I won't separate the other mentioned packages from vdsm-python. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- *Yaniv Bronhaim.*
Yaniv Bronheim <ybronhei@redhat.com> writes:
If in debian we will have different set of rpms for vdsm, can you please also add section about how to build and install vdsm over debian in https://www.ovirt.org/Vdsm_Developers ?
Sure, I'm going to update Debian information on Wiki (as well as to announce it on the mailing lists) once all the packages are in Debian and (basically) working. FYI, cpopen, pthreading, ioprocess, and MoM are already in Debian unstable. I work on safelease and Vdsm now.
On Fri, Jan 22, 2016 at 5:52 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Yaniv Bronheim <ybronhei@redhat.com> writes:
If in debian we will have different set of rpms for vdsm, can you please also add section about how to build and install vdsm over debian in https://www.ovirt.org/Vdsm_Developers ?
Sure, I'm going to update Debian information on Wiki (as well as to announce it on the mailing lists) once all the packages are in Debian and (basically) working.
FYI, cpopen, pthreading, ioprocess, and MoM are already in Debian unstable. I work on safelease
Note that safeelase requires several packages which are *not* required for safelease, but for vdsm. Currently vdsm is noarch rpm, so it cannot require arch specific packages. since it requires safelease, we added arch specific packages to safelease. This is a ugly hack, and more important, may be incompatible with the packaging rules for the platform. Nobody from Fedora complained about it so far, but Debian packagers may be more strict about this. See https://gerrit.ovirt.org/43096 Nir
Nir Soffer <nsoffer@redhat.com> writes:
Note that safeelase requires several packages which are *not* required for safelease, but for vdsm.
Currently vdsm is noarch rpm, so it cannot require arch specific packages. since it requires safelease, we added arch specific packages to safelease.
Thank you for making me aware about those dependencies. The same problem exists in Debian, I'll think how to handle it (making vdsm package architecture specific being the obvious default choice, the safelease hack is out question).
I'd love to have such handling also in our rpm build.. we started some work in https://gerrit.ovirt.org/#/c/42491 , lets try to align the handling in both debian and fedora packaging. feel free to post a patch for that as well and I promise to push it forward On Mon, Jan 25, 2016 at 10:14 AM, Milan Zamazal <mzamazal@redhat.com> wrote:
Nir Soffer <nsoffer@redhat.com> writes:
Note that safeelase requires several packages which are *not* required for safelease, but for vdsm.
Currently vdsm is noarch rpm, so it cannot require arch specific packages. since it requires safelease, we added arch specific packages to safelease.
Thank you for making me aware about those dependencies. The same problem exists in Debian, I'll think how to handle it (making vdsm package architecture specific being the obvious default choice, the safelease hack is out question). _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- *Yaniv Bronhaim.*
On Fri, Jan 22, 2016 at 12:08:16PM +0200, Nir Soffer wrote:
On Fri, Jan 22, 2016 at 11:28 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com> wrote:
On Thu, Jan 21, 2016 at 5:02 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I work on inclusion of Vdsm into Debian. I don't know what are the reasons for having separate `infra', `xmlrpc', `yajsonrpc', and `jsonrpc' packages.
- infra package contains infra related modules like zombiereaper, sygutils (core infra utils)
There is no technical reason to have this package, it should be merge into vdsm-python.
+1. Everything that is not storage, virt, gluster or network, is "infra" by definition.
- xmlrpc package contains xmlrpc binding code (optional and can be disabled in config.py) this package will be removed once we decide to drop xmlrpc
Hopefully we can drop this after 4.0
- jsonrpc package contains jsonrpc binding code (optional and can be disabled in config.py) this package is required to process jsonrpc based rpc calls
This is not optional in 3.6, there is no reason to have it as separate package, should be merged into vdsm-python.
- yajsonrpc package contains stomp related server side code (required for rpc)
Same, no reason to have this as separate package, should be merge into vdsm-python
- api package contains vdsm and gluster (optionally) schemas and code to process them used for rpc validation required by jsonrpc
This package may be needed by vdsm clients, so it should be a separate package.
We have too many packages, which make installation and upgrade harder for no reason. Lets simplify packaging for 4.0.
We require the same version of all vdsm-xxx packages - upgrading only one package is not supported or tested.
On Sun, Jan 24, 2016 at 10:05 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Jan 22, 2016 at 12:08:16PM +0200, Nir Soffer wrote:
On Fri, Jan 22, 2016 at 11:28 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com> wrote:
On Thu, Jan 21, 2016 at 5:02 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I work on inclusion of Vdsm into Debian. I don't know what are the reasons for having separate `infra', `xmlrpc', `yajsonrpc', and `jsonrpc' packages.
- infra package contains infra related modules like zombiereaper, sygutils (core infra utils)
There is no technical reason to have this package, it should be merge into vdsm-python.
+1. Everything that is not storage, virt, gluster or network, is "infra" by definition.
And we don't have storage, virt, or network packages. Even if we had, infra is never optional component, so it should not be separate package.
- xmlrpc package contains xmlrpc binding code (optional and can be disabled in config.py) this package will be removed once we decide to drop xmlrpc
Hopefully we can drop this after 4.0
- jsonrpc package contains jsonrpc binding code (optional and can be disabled in config.py) this package is required to process jsonrpc based rpc calls
This is not optional in 3.6, there is no reason to have it as separate package, should be merged into vdsm-python.
- yajsonrpc package contains stomp related server side code (required for rpc)
Same, no reason to have this as separate package, should be merge into vdsm-python
- api package contains vdsm and gluster (optionally) schemas and code to process them used for rpc validation required by jsonrpc
This package may be needed by vdsm clients, so it should be a separate package.
We have too many packages, which make installation and upgrade harder for no reason. Lets simplify packaging for 4.0.
We require the same version of all vdsm-xxx packages - upgrading only one package is not supported or tested.
participants (5)
-
Dan Kenigsberg -
Milan Zamazal -
Nir Soffer -
Piotr Kliczewski -
Yaniv Bronheim