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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
