On Mon, Aug 8, 2016 at 6:07 PM, Kevin Fenzi kevin@scrye.com wrote:

So, how does this work? Does it make the repo from the sources in lookaside each time? or does it (optionally?) replace the lookaside sources entirely?

I am only vaguely familiar with how rel-eng tools works so I am not entirely sure. However, it seems to me that support for this was implemented on build system side. I've tried scratch-build and it went fine but local mockbuild failed for me, complaining that dist-git repo is missing sources file. Also, buildSRPMFromSCM task that was created for my scratch build contained checkout.log where I could see that build system checked out my git repo and then it created tar archive that was subsequently gzipped and used to build src.rpm (observed in mock_output.log)

Here is workflow from packager perspective, i.e. what was necessary to do to successfully build a scratch build. Packager drops sources file from dist-git repo and instead adds source-repos file. It contains link to git repo and commit hash (on one line separated by white-space), Source0 in spec file then says <package-name>-{%commit_id}.tar.gz (commit_id is usually defined as a macro). Once you've set up git repo with exploded sources and downstream patches on top of that then you can delete all patches from dist-git and from spec file. In my case it was also necessary to update invocation of %setup macro.

We would want to get approval from releng/fesco, but if it's not too much work to add in, it might be fine.

I don't know how much code is needed to implement this, because I couldn't find a commit introducing this functionality internally.

Are there any docs on how it works, etc?

I found an internal wiki page about this feature.

Michal

On Tue, Aug 9, 2016 at 4:41 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:

...

...

...

...

...

"MS" == Michal Sekletar msekleta@redhat.com writes:

MS> Recently, internally they introduced very nice feature that might be MS> also useful to Fedora packagers. It is the ability to build packages MS> from exploded sources. Packager no longer uploads tarball to MS> lookaside cache and maintains patches in dist-git, but points rhpkg MS> (internal equivalent of fedpkg) to git repo that contains exploded MS> sources with downstream patches applied on top. This allows for easy MS> cherry-picking of patches between branches and a ton of other nice MS> features that make maintainer's life easier.

I know this is the infra list, but as a packaging committee member I figured I'd comment.

From a packaging standpoint I'd be happy to see something like this allowed in Fedora, with some caveats (which I'm coming up with on the fly, so don't hate on me if they're dumb):

1. Probably only if the upstream development model works this way. If upstream expects people to work from tarballs, it's probably better to work that way too. Maybe not, though; I don't really have enough info.

I was thinking more in terms of an additional option available to Fedora packagers rather than replacement for current workflow. IOW, use it if it makes sense for given package and actually makes package maintenance easier.

2. The builds must obviously be repeatable using just the srpm.

Shouldn't be a problem.

3. The tooling must make it very simple to duplicate the exploded tree in which you develop using just the spec, patches, and a checkout from upstream.

I am not sure I understand this one correctly...Anyway, once you set up source tree somewhere (we haven't discussed where yet) you can easily git clone it to as many places as you want.

Also, it would be nice to see how the workflow goes and how it differs from the way you work with stacked patch applications and "%autosetup -S git". I'm sure even a simple doc would be enough to sell this.

I think that with current tooling the best option is to use %autosetup -S git_am as it makes history more readable, i.e. commit messages have useful information.

Michal