Looking for %{forgemeta} GitHub example

[Ian Pilcher]

Can anyone suggest a good (simple) example SPEC file that I can
reference as an example of how to use the forgemeta macro?

I'm trying to build SPEC files for a couple of personal GitHub-hosted
projects, and I'd like to make them as robust as possible.  Even though
I have no current plans to try to get the software into Fedora, I've
always considered the Fedora packaging guidelines to be a solid guide
for general RPM development.

I've read the "Referencing Source" page[1], but I don't really
understand what the actual steps are to use the %{forgemeta} macro.
(I'm not even clear on whether it's available on my system; Fedora
doesn't seem to include the redhat-rpm-templates package referenced on
that page.

Thanks!

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

[Fabio Valentini]

On Mon, Feb 21, 2022 at 9:55 PM Ian Pilcher <arequipeno(a)gmail.com&gt; wrote:
>  Can anyone suggest a good (simple) example SPEC file that I can
>  reference as an example of how to use the forgemeta macro?
>
>  I'm trying to build SPEC files for a couple of personal GitHub-hosted
>  projects, and I'd like to make them as robust as possible.  Even though
>  I have no current plans to try to get the software into Fedora, I've
>  always considered the Fedora packaging guidelines to be a solid guide
>  for general RPM development.
>
>  I've read the "Referencing Source" page[1], but I don't really
>  understand what the actual steps are to use the %{forgemeta} macro.
>  (I'm not even clear on whether it's available on my system; Fedora
>  doesn't seem to include the redhat-rpm-templates package referenced on
>  that page.
>
>  Thanks!
>
>  [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ 
Hi!

I would recommend that you use the standard source handling as
documented on the SourceURL page.
The forge macros are no longer actively maintained or developed, the
last fix / update they received was almost two years ago.
The original author is no longer contributing to Fedora, and nobody
else seems to understand how the lua scripts behind those macros work.

So, if you plan to package releases / tags from your GitHub project,
just use what's documented here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git...

Fabio

[Ian Pilcher]

On 2/21/22 15:09, Fabio Valentini wrote:
>  So, if you plan to package releases / tags from your GitHub project,
>  just use what's documented here:
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git... 
Glad I asked.  Thanks!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

[Mattia Verga]

Il 21/02/22 22:09, Fabio Valentini ha scritto:
>  Hi!
>  I would recommend that you use the standard source handling as
>  documented on the SourceURL page.
>  The forge macros are no longer actively maintained or developed, the
>  last fix / update they received was almost two years ago.
>  The original author is no longer contributing to Fedora, and nobody
>  else seems to understand how the lua scripts behind those macros work.
>  
So, shall we remove the reference to %forgemeta macros from the
Packaging Guidelines?

I'd like to have only one recommended way to make things listed in PG.
Having more is confusing for new packagers (and experienced also).

The same applies for %autorelease and %autochangelog. Either recommend
the use of them or not, instead of saying "pick what you like". It seems
to me that these two were adopted in a hurry, but now the development
has almost stopped...

Mattia

[Brandon Nielsen]

On 2/22/22 1:19 AM, Mattia Verga via devel wrote:
>  Il 21/02/22 22:09, Fabio Valentini ha scritto:
> > Hi!
> > I would recommend that you use the standard source handling as
> > documented on the SourceURL page.
> > The forge macros are no longer actively maintained or developed, the
> > last fix / update they received was almost two years ago.
> > The original author is no longer contributing to Fedora, and nobody
> > else seems to understand how the lua scripts behind those macros work.
> >
>  So, shall we remove the reference to %forgemeta macros from the
>  Packaging Guidelines?
>  
>  I'd like to have only one recommended way to make things listed in PG.
>  Having more is confusing for new packagers (and experienced also).
>  
>  The same applies for %autorelease and %autochangelog. Either recommend
>  the use of them or not, instead of saying "pick what you like". It seems
>  to me that these two were adopted in a hurry, but now the development
>  has almost stopped...
>  
>  Mattia
>   
I would like to see the forge macros removed from the guidelines if 
development truly has ceased. I just switched a bunch of stuff I build 
on copr over, and am now moderately annoyed. Out of date documentation 
is often worse than no documentation.

[Jason L Tibbitts III]

> >>>> Brandon Nielsen <nielsenb(a)jetfuse.net&gt; writes:
>  I would like to see the forge macros removed from the guidelines if
>  development truly has ceased. 
I would like to get into them and at least see what needs to change
but... the internal implementation is somewhat baroque and my time is
severely limited.  I think there is good stuff there but I don't know
how much work would be required to salvage it.

One problem is that at least I thought that significant portions of the
Go tooling relied on it, and there's no alternative that has any kind of
automation.

 - J<

[Fabio Valentini]

On Tue, Feb 22, 2022 at 8:57 PM Jason L Tibbitts III <j(a)tib.bs&gt; wrote:
>  >>>>> Brandon Nielsen <nielsenb(a)jetfuse.net&gt; writes:
>
>  > I would like to see the forge macros removed from the guidelines if
>  > development truly has ceased.
>
>  I would like to get into them and at least see what needs to change
>  but... the internal implementation is somewhat baroque and my time is
>  severely limited.  I think there is good stuff there but I don't know
>  how much work would be required to salvage it.
>
>  One problem is that at least I thought that significant portions of the
>  Go tooling relied on it, and there's no alternative that has any kind of
>  automation. 
I don't think removing the forge macros would be possible at this
point, exactly for this reason.

However, Go and Font packaging macros are the only things where using
those macros is not optional, and in both cases, you're supposed to
use wrapper macros so you're not even using the %forgefoo macros
directly.

So I don't think they need to be documented as a standalone feature
any longer, especially since they don't really provide value for
standard GitHub tarball downloads etc. compared to the "old" SourceURL
guidelines we've had for years, and are no longer maintained.

Should we remove documentation for them from the SourceURL guidelines
page? It seems to cause more confusion than it solves problems.

Fabio

[PGNet Dev]

>  especially since they don't really provide value for
>  standard GitHub tarball downloads etc. compared to the "old" SourceURL 
some of us strongly disagree.  admittedly, with no weight ...

[Fabio Valentini]

On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev <pgnet.dev(a)gmail.com&gt; wrote:
>  > especially since they don't really provide value for
>  > standard GitHub tarball downloads etc. compared to the "old" SourceURL
>
>  some of us strongly disagree.  admittedly, with no weight ... 
Admittedly, packages like the .spec for nginx you linked are very far
outliers regarding package complexity.
I doubt there's many packages that need to reference *that* many
different source repos and tarballs ...

For these really complex cases, the forge macros are ~fine~, I guess.
But you really don't - and shouldn't - need to rely on hundreds of
lines of complex lua macros to be able to specify one or two GitHub
tarballs.

Fabio

[PGNet Dev]

On 2/24/22 10:12 AM, Fabio Valentini wrote:
>  On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev <pgnet.dev(a)gmail.com&gt;
> wrote:
> >
> >> especially since they don't really provide value for
> >> standard GitHub tarball downloads etc. compared to the "old" SourceURL
> >
> > some of us strongly disagree.  admittedly, with no weight ...
>  
>  Admittedly, packages like the .spec for nginx you linked are very far
>  outliers regarding package complexity. 
Perhaps very far outliers for _your_ use cases.  Quite common, here.  Especially for
numbers of enterprise packages that, for better or worse, lag upstream in either versions,
or capabilities.

And the flexibility to address that level of 'complexity' is exactly what we look
to a major-distro's build systems for.
My wholesale move(s) to Fedora from Opensuse were well-considered -- and long overdue. For
a large number of reasons.
The biggest risk was the drop in functionality/flexibility of the build system -- for
end-user use cases, NOT necessarily (just) for official packaging.
COPR + the forgemeta stuff gets a heck of a lot closer to par, than not.

>  I doubt there's many packages that need to reference *that* many
>  different source repos and tarballs ...
>  
>  For these really complex cases, the forge macros are ~fine~, I guess. 


>  But you really don't - and shouldn't - need to rely on
> hundreds of
>  lines of complex lua macros to be able to specify one or two GitHub
>  tarballs. 
With that I don't disagree in the slightest.
I've repeatedly advocated for a different approach, similar to OBS' capabilities.
It got zero traction/interest.
So forgemeta seems to be "functionally best available" option, currently.

It would be far less of a concern if ANY of those discussions had gotten any traction, and
there was a good/flexible ALTERNATIVE to forgemeta, rather than simply talk of deprecating
current capabilities, without a good option.

There _are_ options, of course.  And I have two in place -- our own, LFS distro with rpm
build system, and building Fedora+pkgs on OBS.
Neither are optimal, both are costly, and in both cases I'd prefer something @Fedora
buildsys.

But again, i ACK that 'my' needs have little weight.

[Ben Beasley]

I have stopped using the “forge” macros in most cases where I am packaging a release/tag,
since the URLs are simple enough without them, usually something like

URL: https://github.com/foo/bar
Source0: %{url}/archive/v%{version}/bar-%{version}.tar.gz

However, when I need to package an untagged commit, the ability of the “forge” macros to
automatically construct and apply the snapshot information field, including picking up the
date from the primary source’s mtime, is *awesome*, even if it’s not that much harder to
do it by hand. It’s also nice to write “%forgeautosetup” instead of “%autosetup -n
bar-%{commit}”.

I guess I’m saying that I could easily live without these macros, but I do find them
occasionally useful in several small ways.

– Ben

On Thu, Feb 24, 2022, at 10:00 AM, PGNet Dev wrote:
>> especially since they don't really provide value for
>> standard GitHub tarball downloads etc. compared to the "old" SourceURL
>
> some of us strongly disagree.  admittedly, with no weight ...
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Brandon Nielsen]

On 2/22/22 1:56 PM, Jason L Tibbitts III wrote:
> >>>>> Brandon Nielsen <nielsenb(a)jetfuse.net&gt;
> writes:
>  
> > I would like to see the forge macros removed from the guidelines if
> > development truly has ceased.
>  
>  I would like to get into them and at least see what needs to change
>  but... the internal implementation is somewhat baroque and my time is
>  severely limited.  I think there is good stuff there but I don't know
>  how much work would be required to salvage it.
>  
>  One problem is that at least I thought that significant portions of the
>  Go tooling relied on it, and there's no alternative that has any kind of
>  automation.
>  
>    - J< 
Looking at this a little more, I'm not really sure we need to be 
discouraging their use. The code[0] doesn't look that bad to me, and 
there are only 2 issues open against it.

The fact nobody is stepping up to at least comment on the two issues is 
a bit of a concern. The first one[1] looks really problematic, and I 
don't see how you can fix it without coordinating with any package using 
the broken behavior. Hopefully it isn't as bad as it looks?

The second one[2] is an RFE, and looks like one I may try to address if 
nobody gets to it before I have some free time.

I do agree with the sentiment elsewhere in this thread that for the 
majority of cases, it's easy enough to just work with the URLs directly. 
Maybe the git forge macro documentation moves somewhere else instead?

[0] - 
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/forge...
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=2048362
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=2035935

[Chris Adams]

Once upon a time, Ian Pilcher <arequipeno(a)gmail.com&gt; said:
>  Can anyone suggest a good (simple) example SPEC file that I can
>  reference as an example of how to use the forgemeta macro? 
Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:

https://cmadams.fedorapeople.org/ks-install/ks-install.spec

-- 
Chris Adams <linux(a)cmadams.net&gt;

[PGNet Dev]

>  Aside from the other follow-ups about whether or not to use them...
>  here's an example of a SPEC I wrote for a proposed package: 
not all are concerned with building according to Fedora Packaging standards, for proposal
in inclusion

some of us use forgemeta because it provides capability that allows us to build what/when
we require

with capabilities approaching Opensuse's OBS. in any case, more flexible than not.

particularly the nice git branch support; incredibly useful, imo.

here's one of mine:

   https://pagure.io/pgnd/nginx-mainline/blob/main/f/nginx/nginx.spec

used for my regular COPR builds.

it would be ... unfortunate ... if forgemeta were to vanish.

my $0.02