Add support for bare %package

[voxik]

Could there be added support for bare %package, without any argument or option? Several reasons I can think of.

1. Having plain %description / %files without its %package counterpart is asymmetric
2. Having bare %package somewhere in the .spec file could allow to use the original preamble (if present) just in SRPM context.
3. Having bare %package would allow to place the main package declaration freely in .spec file.

The third point is actually my original motivation related to #2892. I believe that if I replaced the License: tags by some macro, I could likely accumulate the licenses and use them in the %package which would be listed as last. This in turn would likely allowed me to conditionalize the sub-package existence.

IOW the most naive (and incomplete) example could look like this:

%package libs
Summary: foo-libs

%description libs
foo-libs description

%package
Summary: foo
Name: foo
Version: 1
Release: 1%{?dist}
License: MIT

%description
foo description

%files

%files libs

%changelog

[pmatilai]

The main package preamble has to come first, the rest of the spec parser is built on top of that assumption.

[voxik]

I wish you could elaborate more. From your answer, I am not able to deduce

1. If you like / not like the idea if you were free from current implementation
2. What it would take to change the implementation
3. If there are any hopes or not

[Conan-Kudo]

So is the idea to be able to mimic the debian/control style of the top preamble actually being for the source package only, and then a bare %package section for the binary package of the same name?

[voxik]

I don't know anything about Debian, but yes, having binary package of different name is one of the motivations. But to me, this is optional depending if this scenario was supported.

Nonetheless, I think that being able to define subpackages before preamble is beneficial on itself and it would help to remove hacks such as:

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/b7d1bfae1fb673c4d8a21a8866ba4e37b2cd6eaf/f/common.lua#_217-235

(and it does not mean that I necessarily defend purpose and implementation of those macros)