Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
X. Requires some files in upstream repo
I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.
On Fri, Sep 9, 2016 at 4:47 PM, John Florian <john.florian(a)dart.biz> wrote:
On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
I would like to build (S)RPMs directly from a Git repository (which
contains the .spec file in the top-level directory). This is for a
CI-style project, with a quick release cycle.
I have a Lua script fragment which generates a proper SRPM with the
mock-scm target in COPR, and which is also compatible with “fedpkg
srpm”. But rpmbuild strips leading path components from Source: and
Patch: references, so this only works if all files are in a single
directory.
Are there any alternatives that work in COPR, EPEL and Fedora proper?
I think it's strange that I have to put a tarball somewhere just for
RPM's sake if there is no separate upstream, and there are no upstream
releases as a result. It's just an annoyance and yet another step that
can go wrong in various ways.
This is my situation with everything I package (privately for my employer).
I went in circles for a while simply believing I had to be doing something
wrong until I considered the fact that most people doing packaging are not
the authors. This all settled in completely when I began recalling the days
of yore when one would download a tgz, extract, config, make, etc.. Still I
think it's a shame that this isn't handled better. With very large projects
it's quite a waste of time to archive just to meet the expected input format
only to have the process reversed immediately.
That said, I do much as Igor has already mentioned. My build process starts
with tito but lands in our Koji. I use the following Makefile without any
changes for each of my projects to facilitate tito's
tito.release.KojiGitReleaser:
$ cat Makefile
# Extract NVR from the spec while stripping any macros, specifically the
# disttag macro.
name := $(shell awk '/^Name:/{print $$2}' *.spec)
version := $(shell \
awk '/^Version:/{print gensub(/%{.*?}/, "", "g",
$$2)}' *.spec \
)
release := $(shell \
awk '/^Release:/{print gensub(/%{.*?}/, "", "g",
$$2)}' *.spec \
)
# The treeish we'll archive is effectively the Git tag that tito created.
treeish := ${name}-${version}-${release}
# Koji's buildSRPMFromSCM method expects a target named "sources" which
# ultimately must ensure that a tarball of the package's sources and its
spec
# file are present. Our practice is to always keep a spec file in the Git
# repository, but we must build the tarball on the fly to resemble an
upstream
# published work.
sources:
git archive \
--output=${name}-${version}.tar.gz \
--prefix=${name}-${version}/ \
${treeish}
Hope this helps!
--
John Florian <john.florian(a)dart.biz>
--
devel mailing list
devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org