On 2/24/22 10:12 AM, Fabio Valentini wrote:
On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev <pgnet....@gmail.com> 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.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to