Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
With regards, Daniel
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
~~~
%{load:%{S:1}}
~~~
Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
Vít
With regards, Daniel
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case. That's what we do for other languages like Python, in python-rpm-macros...
Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case.
They are packaged of course, either in rubygem-devel or in ruby-devel
That's what we do for other languages like Python, in python-rpm-macros...
Vít
On Mon, 2024-06-10 at 18:52 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case.
They are packaged of course, either in rubygem-devel or in ruby-devel
But then why would spec files be listing them as a source, which is where this thread started, instead of buildrequiring the appropriate package?
On Mon, Jun 10, 2024 at 10:09:16AM -0700, Adam Williamson wrote:
On Mon, 2024-06-10 at 18:52 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case.
They are packaged of course, either in rubygem-devel or in ruby-devel
But then why would spec files be listing them as a source, which is where this thread started, instead of buildrequiring the appropriate package?
I assume it's to avoid a circular build dependency? This doesn't matter that much, but it does make a theoretical bootstrap from nothing a bit harder.
I didn't know the local "Source: macros.X" was possible before reading this thread, but we could have used it to avoid a circular dependency on RPM macros in both supermin and nbdkit.
Rich.
Dne 10. 06. 24 v 20:18 Richard W.M. Jones napsal(a):
On Mon, Jun 10, 2024 at 10:09:16AM -0700, Adam Williamson wrote:
On Mon, 2024-06-10 at 18:52 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote: > Lately, I noticed that several SPEC files in Fedora use this syntax: > > Source: macros.vlc > > And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file. > > This makes parsing of the SPEC file harder, because any parser have to have > this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
> I mentioned vlc, but it is used in many other packages: valkey, zig, > typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other. > > Why are packagers doing this? I am not saying this is bad, it just surprised > me. I am used to put all macros at the top of the SPEC file and this is new > to me. What is the benefit? I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case.
They are packaged of course, either in rubygem-devel or in ruby-devel
But then why would spec files be listing them as a source, which is where this thread started, instead of buildrequiring the appropriate package?
Because we are using macros such as `%ruby_libdir` during packaging Ruby itself as well as packaging its dependencies.
There could in theory be some completely independent `ruby_rpm_macros` package but this would have its own tradeoffs. The bootstrap, as Rich pints bellow, is certainly easier without such package. Generally, having one less independent package is good once we want to productize Ruby in RHEL.
Vít
I assume it's to avoid a circular build dependency? This doesn't matter that much, but it does make a theoretical bootstrap from nothing a bit harder.
I didn't know the local "Source: macros.X" was possible before reading this thread, but we could have used it to avoid a circular dependency on RPM macros in both supermin and nbdkit.
Rich.
On Mon, Jun 10, 2024 at 08:35:36AM -0700, Adam Williamson wrote:
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
There is also:
%{load:%{S:1}}Which actually loads the file.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
I don't know if it is the case for vlc, but the common benefit would be where the same macros are to be used in both this local spec, and the specs of other dependent RPMs.
That is precisely the reason I have pioneered this approach and using it for Ruby.
It might be nice to package the macros, in that case. That's what we do for other languages like Python, in python-rpm-macros...
I guess there's a distinction here between packaging the macros in their own self-contained RPM, vs packaging them as a sub-RPM of the "main" package. I don't recall our packaging guidelines expressing a preference either way. We seem to have a mix of both approaches across various Fedora packages.
With regards, Daniel
Hello,
On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This makes parsing of the SPEC file harder, because any parser have to have this maro file in current directory - just reading SPEC file is not enough.
I mentioned vlc, but it is used in many other packages: valkey, zig, typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
Why are packagers doing this? I am not saying this is bad, it just surprised me. I am used to put all macros at the top of the SPEC file and this is new to me. What is the benefit?
In linux-system-roles, such files are used to isolate parts that differ beween RHEL and Fedora. This way, merging between RHEL and Fedora is easier, as the spec file can be identical and the differences are in the include files, which differ. As a result, one does not have to deal with merge conflicts when synchronizing from Fedora to RHEL or vice-versa.
See for example the explanation in https://src.fedoraproject.org/rpms/linux-system-roles/raw/rawhide/f/extrasou...
Regards, Pavel
Lately, I noticed that several SPEC files in Fedora use this syntax:
Source: macros.vlc
And this file defines macros that are loaded by rpmbuild during buildtime and are used in the SPEC file.
This isn't how its done everywhere (and I honestly wasn't aware that this was done at all). Zig, for example, only ships it for other packages to make common operations simpler and integrate with the system.
-
Adam Williamson -
Daniel P. Berrangé -
Jan Drögehoff -
Miroslav Suchý -
Pavel Cahyna -
Richard W.M. Jones -
Vít Ondruch