[Tendrl-devel] distribution packaging

[Ken Dreyer]

Hi Martin,

In the past, I've seen issues where commits to upstream projects will
end up breaking the package builds in subtle ways, and it's nice to
keep the RPM .spec file in the same Git repository to catch these.

For example, if the developers add a large feature that adds new files
during "make install" (or equivalent), then the developer has to make
two PRs to two separate Git repositories: one to add the feature, one
to update the RPM packaging for the feature. The first one has to be
merged prior to the second one. And operations like reverts or
cherry-picks become more complicated.

There are already some delays now with the way that Jenkins is not
really doing full RPM builds for every GitHub pull request, but
eventually I think that's where we want to go - having Jenkins do full
RPM builds to test that each PR does not break the packaging.

Just my 2 cents :)

- Ken

On Thu, Feb 23, 2017 at 11:24 AM, Martin Bukatovic <mbukatov at redhat.com> wrote:
> Dear Tendrl community,
>
> I have another proposal related to packaging. And this time it's
> distribution packaging, by which I mean building and maintenance
> of rpm or deb packages. I'm not sure how much my idea make sense
> for us, but it's at lest worth discussion/consideration.
>
> This is important because such packages are main deliverable
> from the end user point of view.
>
> In the rest of this email, let's focus on rpm packages, which
> I'm more familiar with.
>
> To provide rpm package, we need to maintain rpm spec file
> (which fully describes build process of a package) and right
> now, we maintain such spec file in the repository
> of the component directly. Which is definitely a possible
> approach and makes sense. Besides that, I noticed that we
> sometimes needs to maintain spec files for dependencies
> which we use, but target distribution doesn't provide.
> See for example this spec files in tendrl-commons repo:
>
> https://github.com/Tendrl/commons/tree/develop/dependencies
>
> With this in mind, I think that we may consider a different
> approach: to maintain all rpm spec files in dedicated repository,
> which would contain directory for each package. This would be kind
> of in the middle between current approach when all spec files are
> in project repositories directly and fedora dist-git approach which
> uses separate git repository for each rpm specfile.
>
> I'm not proposing fedora dist-git approach since we are using copr
> for our usptream builds and copr doesn't provide dist-git interface
> right now - one needs to push srpm (source rpm) into it to start
> a build. And without support in copr, it would create unreasonable
> additional maintenance cost (note: just to be clear, I know that
> copr uses dist-git internally, but right now it doesn't use it as
> an interface in a way fedpkg/koji does).
>
> Good aspects of this approach:
>
> * all spec files would be on a single place
> * we wouldn't have to remember where a spec file for given
>   dependency is stored (especially when it's necessary for multiple
>   tendrl components)
> * rpm packaging issues would be easier to deal with
>   (as those would be reported in a single repo and
>   would not mix with other issues)
>
> Does this makes sense?
>
> --
> Martin Bukatovic
> USM QE team
>
> _______________________________________________
> Tendrl-devel mailing list
> Tendrl-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/tendrl-devel