More flexible search paths

[LecrisUT]

There is an issue raised by upstream, in that they would like packaging files to be more centralized, e.g. .packit.yaml, .tito, package_name.spec, etc. The reasoning is that the list of files becomes too long, pushing down README.md and LICENSE files. I have opened an issue on tito, and here I just want to mention one relevant part: Search for /.distro/packit.yaml and equivalents.

[lachmanfrantisek]

Hello again!

I really understand the reasoning but a bit of context..;)
For a while, we are trying really havilly to get rid of the high number of name variant. (We even used to support json and other formats.) But even with the packit name and yaml, we have 4 options -- with/without dot, yaml/yml. It does not look like a lot but we are searching for the config quite often. (Actually, a lot; for all the relevant events, we need to realise if we should do something for that event. (A lot of events are irrelevant because of the missing config.) It should be described in this research made by Hunor.) We are fighting both with the limits and speed.

That's why we are trying to avoid if possible yet another config name. Also, if we allow one, another will definitely be requested...;)

Also, someone has already disagreed with using distro for Packit since:

• It should be used purely for the distro files.
• Packit is run in upstream (produces builds/tests statuses), it's not just about a downstream/distribution.

Also, using top directory is common, if not a de-facto standard for all the GitHub actions / CI systems / linters /... And if not agreed on a wider scope of similar systems, this just might be confusing.

So, until it isn't a real blocker for upstream projects to enable Packit and there is not a wider agreement between similar tools, we will stick with the current naming schema. I am going to close this, but in case of any change, implementation-wise, it's a one-liner and we can easily change it.

[LecrisUT]

Thank you and I appreciate having the discussion here. Hopefully it will be easy to search if others encounter a similar request from upstream