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.flor...@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.flor...@dart.biz>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
