Could you please describe more specifically an use case where the current layout does not work?
There are two issues with the current approach:
-
No automatic removal of older versions: With the development, you start to accumulate RPMs for different versions quite fast, as soon as new ones are produced for every try. To combat that, one can use as a version the one in SPEC without extra version info, but that is maybe not the best solution either.
-
As soon as you start getting larger sets of RPMs, it becomes harder to track which one is coming from where. For example, collectd produces collectd-xyz.rpm, libcollectd-xyz.rpm, -devel versions and so on. If each SPEC will be partitioned into separate folder, it would be easier to track it manually.
As a result, we get also
-
If we want to automate detection of provided symbols for automatic build systems (as in https://forum.sailfishos.org/t/automated-build-system-to-handle-multiple-packages), it would simplify scripts by having imposed SPEC->RPM list relationship. Although, this can probably be obtained reliably from
rpmspec. -
Such layout would simplify application of (1) above. Just remove all packages from corresponding RPMS subdir. Otherwise, you may get into situation where packages could have changed in a SPEC and autoremoval on adding new version will break.