On Mon, Dec 14, 2015 at 12:26 PM, Barak Korren <bkorren@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@redhat.com
RHEV-CI Team

Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com