Is the expected workflow to be that I'd put these two lines to my spec file?
%generate_buildrequires
some-tool generate-rpm-buildreqs %{_builddir}
I'm interested if:
1. Generators will be separated from RPM codebase.
2. What the interface b/w a generator and rpm tool will be.
3. What are the expectations for responsibilities? Should I be
expected to invoke the generator or will language ecosystems update
their macro packages to provide wrappers on top
%generate_buildrequires?
Thanks,
Tomas
On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
>
> https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
>
> = BuildRequires Generators =
>
> == Summary ==
> Add possibility to generate build-time dependencies within RPM spec
> file and teach RPM and mock how to handle this.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
> Festi]], [[User:msuchy|Miroslav Suchý]]
> * Email: ignatenkobrain@xxxxxxxxxxxxxxxxx, ffesti@xxxxxxxxxx, miroslav@xxxxxxxx
>
> == Detailed Description ==
> For many languages (Rust, Golang, Node.Js, Ruby, Python),
> BuildRequires can be automatically generated. All it takes, run some
> special tool which will output dependencies in RPM format.
>
> Q: How will it work under the hood?
> A: When you build RPM, something like this will happen under the hood…
> # rpm would perform %prep (which is supposed to abort if some
> dependencies missing and print them)
> # mock would install those dependencies and resume build
>
> Q: Will src.rpm contain all generated dependencies?
> A: This is not known yet, we'll update page once it is known.
>
> Q: Does this mean that package builds won't be reproducible anymore?
> A: No, as long as you have same buildroot and tool which is generating
> BuildRequires is doing so in reproducible manner, it should not affect
> reproducibility.
>
> == Benefit to Fedora ==
>
> Packagers won't have to pre-generate BuildRequires in the spec file
> which means it will be always updated (and correct) :
>
> * Packagers can focus of making their packages better instead of
> spending all their packaging time copying BuildRequires from
> documentation and third party tools.
> * BuildRequires are dropped as soon as they're no longer necessary
> * Packages can be easily bumped without requiring a manual BuildRequires refresh
> * BuildRequires and Requires generation can use similar utilities,
> making sure that the deps packages declare can also be used for
> second-level building. Packages no longer need to declare the deps of
> their second and n-th dependencies because someone forgot to declare
> them in the correct package.
>
> == Scope ==
> * Proposal owners: Implement support for a feature in RPM and mock (if
> implemented properly, Koji should just work). Make use of it in Rust
> ecosystem.
> * Other developers: Maintainers of language stacks are advised to use
> this feature.
> * Release engineering: [https://pagure.io/releng/issue/8129 #8129]
> * Policies and guidelines: Packaging Guidelines need to be updated
> with instructions how to use this feature.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Packagers and users who use repoquery might be affected (src.rpm might
> not contain generated dependencies).
>
> == How To Test ==
> TBD.
>
> == User Experience ==
> Users won't notice differences.
>
> == Dependencies ==
> Required feature needs to be implemented in RPM and mock.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) Proposal
> Owners might still ship feature disabled for Fedora buildsystem but
> have it available for end-users, and move full completion to the next
> release.
> * Contingency deadline: Beta Freeze
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> TBD.
>
> == Release Notes ==
> TBD.
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
