This could also have started as discussion in the Issues section like suggested in the contribution guidelines. But since I did not have any prior knowledge of the codebase, I had to dig quite deep before I could propose a solution that would work. Thus, when I was ready to propose something, the implementation was already more or less done. Thus the approach of starting with a pull request.

Looks promising. I like your approach of sending the PR directly (and even with unittests).

• So far it doesn't work for me. But maybe I missed something. I tested it in "setup.py development" mode. And changed rhpkg.conf. I can not see "results" dir after "rhpkg local".
• There is a commit message that uses long lines and syntax features that Pagure supports. But the message is broken in "git log" view. Description in Pagure is OK, would it be possible to modify the commit message?
• rpkg.conf - maybe it is not necessary (but it is not wrong either). After installation of rpkg this config is not really used. Proper config has to be modified in rhpkg/fedpkg after release.
• Jenkins tests (https://jenkins-fedora-infra.apps.ci.centos.org/job/pyrpkg/473/Builders=F29/console) fails on Python2.7 (this has to be supported because of RHEL7). I am not sure what happened and I will have to look at it more. Currently, tests are not triggered automatically because of some external infrastructure issue.
• Also flake8 shows some minor syntax issues.

Ondrej,

Thank you reviewing this.

• I added line break to commit message and removed some Markdown that was not really plaintext friendly. I hope the message now looks better.
• I removed the rpkg.confchange. No need to have it there if it is not necessary. It would be great if there was a place to document different configuration options. Unfortunately, doc/source/configuration.rst is empty, I did not see the point in adding only one option there, and did not know what to write about many existing ones, so putting something to rpkg.conf was my best attempt at documentation, as inadequate as it was.
• I went through flake8's complaints and fixed everything.
• Regarding it not working...well, it does not work for me either if I remove the fedpkg patch I had to apply to get it working. I added the patch in my fedpkg fork so you can take a look. Basically, fedpkg was ignoring the whole rpg layout setup and settings its own rpmdefines. And since this pull request is based on layouts, that patch was necessary. I though that this was a bug in fedpkg and I could submit the fix to fedpkg next, in case this pull request gets accepted. But, if you say this pull request does not work with rhpkg either, could it be that the same thing is going on there, too? If so, maybe it is not so much that fedpkg has a bug, but that they are (in practice at least) an obsolete feature that no user of rpkg should depend on? If so, this pull request needs more than minor changes (and layouts could be removed from the codebase as dead code).

Now that I took another look at this, I realized that in addition to items that were already sent to results directory, also sources from lookaside cache should go there. I added that, too. Probably all this should be a single commit if the pull request is merged, but since I am making changes in middle of review, I added another (temporary) commit so the addition can be viewed separately.

It turns out source download was also bypassing the layout completely, always using rootdir as source location.

• commit messages look better now
• thanks for fixing flake8 complaints and unittests failures.
• Unfortunately, there is no such documentation so far. I describe newly added functionality in a releases section of web documentation. I know that it is not fortunate in case you are looking for a general summary regarding configuration.
• I patched the fedpkg to try the functionality, but fedpkg prep stopped working to me. It was unable to find patches. I tried to build rpkg dist-git repository:

Cannot read /repo/rpkg-fedora/results/remove-koji-and-rpm-py-installer-from-requires.patch

Oh, I had a bad example package that did not have any patches. I now realize that patches should be in the sourcedir. Since patches are already at repository root (in at least Fedora repositories), sourcedir has to be the root. I reverted the sourcedir change. Now, for me, all this runs well:

$ fedpkg clone rpkg
$ cd rpkg
$ fedpkg prep
$ fedpkg srpm
$ fedpkg mockbuild

fedpkg local runs otherwise, but produces a lot of test failures. They seem to be related to Fedora's recent branch name change from master to rawhide/main — some assumption in rpkg's test suite seems to clash with running the tests inside a git repository that does not have a branch named master. i tested with another package, rubygem-jekyll, which completed successfully (in f33 branch matching my environment).

I apologize for repeatedly submitting faulty code. I hope everything is alright now.

I should also note at this point that the path to getting to relatively meager goal of simplifying .gitignore rules has been more convoluted than I initially expected. In case problems continue to surface, I am not at all offended if the decision is to drop this pull request due to weak cost benefit ratio.

I would like to have this option available.

Due to a lot of variety in how specfiles are worked with, there is unfortunately a lot of potential for conflicts and edge cases. While I think it would be a good change to enable by default (in fedpkg), maybe it would be nice to first ship it disabled, and let users know how to enable this to test it. That way feedback could be gathered from wider audience and possible bugs fixed.

Hi @lsedlar ,

I am happy to hear that you think it is a good feature. And yes, the idea is that it is opt-in. fedpkg default configuration in Fedora should set it to root so current behavior is retained. Also, the code it written in such a way that if config file does not have anything set, root is the default. The later, discussion about switching the default config to subdir, if users like the new style.

Merged, great!

Follow-up pull request for fedpkg here: fedpkg#432