7:25 a.m.
We currently manage debian packaging files under
https://gerrit.ovirt.org/#/q/project:releng-tools instead of in the project
itself. imo it makes it harder, as developer won't update the debian folder
while changing spec parts , which makes much more observation work for
Simone..
But if we keep to manage debian that way we should remove the debian folder
from cpopen, vdsm, pthreading to avoid duplication.
Simone can you explain more how you manage to flow code changes and update
the debian support currently? should I indeed drop the current debian code
that we have in vdsm?
--
*Yaniv Bronhaim.*
5:13 a.m.
On Sun, Dec 13, 2015 at 2:25 PM, Yaniv Bronheim <ybronhei(a)redhat.com> wrote:
We currently manage debian packaging files under
https://gerrit.ovirt.org/#/q/project:releng-tools instead of in the
project itself. imo it makes it harder, as developer won't update the
debian folder while changing spec parts , which makes much more observation
work for Simone..
But if we keep to manage debian that way we should remove the debian
folder from cpopen, vdsm, pthreading to avoid duplication.
Simone can you explain more how you manage to flow code changes and update
the debian support currently? should I indeed drop the current debian code
that we have in vdsm?
--
*Yaniv Bronhaim.*
Issue with keeping debian subdir within the package itself is that it's
totally useless unless maintained.
When a new release is issued just tagging the code won't be enough anymore
because debian changelog expect to be updated with the release version. So
tagging vdsm-4.17.14 without having 4.17.14 in the changelog will cause the
package to fail the build (while rpm just issue a error in rpmlint... )
having a separate repo decouple the distribution packaging from the package
itself and make it easier to handle at release time.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
5:26 a.m.
Issue with keeping debian subdir within the package itself is that it's
totally useless unless maintained.
When a new release is issued just tagging the code won't be enough anymore
because debian changelog expect to be updated with the release version. So
tagging vdsm-4.17.14 without having 4.17.14 in the changelog will cause the
package to fail the build (while rpm just issue a error in rpmlint... )
having a separate repo decouple the distribution packaging from the package
itself and make it easier to handle at release time.
While I have very little stake in this, I have to say that looking at
this from the side, it looks strange that RPM is supported as a
primary build target for all projects while DEB needs a separate repo.
Maybe the build scripts should be made smarter and work around Debians
limitations (For example let the makefile dynamically generate the
changelog form the tags)?
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
5:59 a.m.
On Mon, Dec 14, 2015 at 12:26 PM, Barak Korren <bkorren(a)redhat.com> wrote:
>
> Issue with keeping debian subdir within the package itself is that it's
> totally useless unless maintained.
> When a new release is issued just tagging the code won't be enough
anymore
> because debian changelog expect to be updated with the release version.
So
> tagging vdsm-4.17.14 without having 4.17.14 in the changelog will cause
the
> package to fail the build (while rpm just issue a error in rpmlint... )
>
> having a separate repo decouple the distribution packaging from the
package
> itself and make it easier to handle at release time.
>
While I have very little stake in this, I have to say that looking at
this from the side, it looks strange that RPM is supported as a
primary build target for all projects while DEB needs a separate repo.
Maybe the build scripts should be made smarter and work around Debians
limitations (For example let the makefile dynamically generate the
changelog form the tags)?
rpm build works just because rpm is not as strict as debian.
there's a reason if fedora, rhel, centos uses dist-git with external spec
file instead of rely on the spec file we ship within the tarball.
The spec included in the tarball is not production / enterprise level ready.
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
6:10 a.m.
On Mon, Dec 14, 2015 at 1:59 PM, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
On Mon, Dec 14, 2015 at 12:26 PM, Barak Korren <bkorren(a)redhat.com> wrote:
>
> >
> > Issue with keeping debian subdir within the package itself is that it's
> > totally useless unless maintained.
> > When a new release is issued just tagging the code won't be enough
> > anymore
> > because debian changelog expect to be updated with the release version.
> > So
> > tagging vdsm-4.17.14 without having 4.17.14 in the changelog will cause
> > the
> > package to fail the build (while rpm just issue a error in rpmlint... )
> >
> > having a separate repo decouple the distribution packaging from the
> > package
> > itself and make it easier to handle at release time.
> >
>
> While I have very little stake in this, I have to say that looking at
> this from the side, it looks strange that RPM is supported as a
> primary build target for all projects while DEB needs a separate repo.
> Maybe the build scripts should be made smarter and work around Debians
> limitations (For example let the makefile dynamically generate the
> changelog form the tags)?
rpm build works just because rpm is not as strict as debian.
there's a reason if fedora, rhel, centos uses dist-git with external spec
file instead of rely on the spec file we ship within the tarball.
The spec included in the tarball is not production / enterprise level ready.
Strange, I understood from Eyal that we push the spec vdsm generates
to dist-git, and this is the spec used for the build.
Patches to make the spec production/ enterprise ready are welcome :-)
>
>
>
> --
> Barak Korren
> bkorren(a)redhat.com
> RHEV-CI Team
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3268
days inactive
3269
days old
4 comments
4 participants
participants (4)
-
Barak Korren -
Nir Soffer -
Sandro Bonazzola -
Yaniv Bronheim