Re: F31 System-Wide Change proposal: BuildRequires Generators
The change proposal is about integrating an entry point in rpmbuild to accept BR lists, at a moment of the build process where sources are already unpacked and processed. It's an entry point. It does not restrict how you generate the BR data (upstream command, macro, cat somefile, echo foo, a mix of all of those, whatever works for the spec writer) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
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 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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com,
> miros...@suchy.cz
>
> == 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
Dne 18. 02. 19 v 21:19 Ben Cotton napsal(a): > 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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, > miros...@suchy.cz > > == Detailed Description == > For many languages (Rust, Golang, Node.Js, Ruby, Python), While Ruby is mentioned here, I can't imagine it would be of any use for Ruby packages. Ruby packages has nothing like "build requires". They have "development" dependencies, but that is something completely different. These are typically needed to execute test suite and executing test suite is not always easy task. Therefore even gem2rpm currently outputs the development dependencies just as a set of BuilrRequires which are commented out by default. Vít > 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. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On 2/22/19 1:01 PM, Petr Viktorin wrote: On 2/18/19 9:19 PM, Ben Cotton 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. I am very excited about this change. Count with me for Python. Is there a (draft) API to start coding against? In Python, there's an effort to enable things like this generator, e.g. [PEP 517]. Here, gathering BuildRequires is a two-step process: - the "build backend" is specified in declarative metadata; - then the build backend can query backend-specific metadata for additional BuildRequires. Is that possible with the current plans? It's really way too early to say much anything one way or the other, this change proposal was submitted rather *cough* optimistically *cough*. If interested, chime in at upstream: https://github.com/rpm-software-management/rpm/pull/593 https://github.com/rpm-software-management/rpm/issues/104 - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
Once upon a time, Petr Viktorin said: > Yes, automagic generators don't work in the long run. Requirements > are always better listed explicitly. Perl has been using automatic generators for ages. They're not perfect, but they're really good and work fine in the most common cases. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On Fri, Feb 22, 2019 at 6:01 AM Petr Viktorin wrote: > > On 2/18/19 9:19 PM, Ben Cotton 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. > > > I am very excited about this change. Count with me for Python. Is there > a (draft) API to start coding against? > > In Python, there's an effort to enable things like this generator, e.g. > [PEP 517]. > > Here, gathering BuildRequires is a two-step process: > > - the "build backend" is specified in declarative metadata; > - then the build backend can query backend-specific metadata for > additional BuildRequires. > > Is that possible with the current plans? > > > BTW: New versions of Python's usual build system (setuptools/setup.py) > will be forward compatible with PEP 517. Please do not write generators > that use setup.py directly. We currently have no BuildRequires generators written yet, so we can Do It Right(TM) for this. :) That said, I'm not sure how we will be broadly compatible for divining setup_requires if they are specified... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On 2/22/19 12:01 PM, Petr Viktorin wrote: On 2/18/19 9:19 PM, Ben Cotton 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. I am very excited about this change. Count with me for Python. Is there a (draft) API to start coding against? In Python, there's an effort to enable things like this generator, e.g. [PEP 517]. Missing footnote: [PEP 517]: https://www.python.org/dev/peps/pep-0517/ specifically: https://www.python.org/dev/peps/pep-0517/#get-requires-for-build-wheel Here, gathering BuildRequires is a two-step process: - the "build backend" is specified in declarative metadata; - then the build backend can query backend-specific metadata for additional BuildRequires. Is that possible with the current plans? BTW: New versions of Python's usual build system (setuptools/setup.py) will be forward compatible with PEP 517. Please do not write generators that use setup.py directly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On 2/18/19 9:19 PM, Ben Cotton 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. I am very excited about this change. Count with me for Python. Is there a (draft) API to start coding against? In Python, there's an effort to enable things like this generator, e.g. [PEP 517]. Here, gathering BuildRequires is a two-step process: - the "build backend" is specified in declarative metadata; - then the build backend can query backend-specific metadata for additional BuildRequires. Is that possible with the current plans? BTW: New versions of Python's usual build system (setuptools/setup.py) will be forward compatible with PEP 517. Please do not write generators that use setup.py directly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On 2/19/19 7:04 PM, Raphael Groner wrote: Hi, maybe you already noticed, there's a project called pipreqs that parses python code for import statements. We've already a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1665749 Although, I doubt in general that any automagic with dependency generators brings a huge benefit in the long run. In case of python projects, I see sometimes conditional dependencies that enable optional features by awareness of any existance of a library, e.g. SecretStorage that parses for alternative desktops and optional password storage. Further, mostly there are up to 5 dependencies to note but sometimes 2 to ignore anyways. Yes, automagic generators don't work in the long run. Requirements are always better listed explicitly. However, for most Python projects they *are* listed explicitly -- in the Python package metadata. And there are efforts upstream to make this metadata more usable for automation. Currently, that metadata needs to be copied, by hand, to RPM BuildRequires. That's what a generator can automate. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
Le mardi 19 février 2019 à 18:04 +, Raphael Groner a écrit : > > Although, I doubt in general that any automagic with dependency > generators brings a huge benefit in the long run. That depends on the amount of deps the language uses. Human handcrafting is always better but it does not scale past a certain amount of dep and dep changes that need managing Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
Hi, maybe you already noticed, there's a project called pipreqs that parses python code for import statements. We've already a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1665749 Although, I doubt in general that any automagic with dependency generators brings a huge benefit in the long run. In case of python projects, I see sometimes conditional dependencies that enable optional features by awareness of any existance of a library, e.g. SecretStorage that parses for alternative desktops and optional password storage. Further, mostly there are up to 5 dependencies to note but sometimes 2 to ignore anyways. Just my 5ct. Raphael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On Mon, Feb 18, 2019 at 4:36 PM Dridi Boukelmoune wrote: > > On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton 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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, > > miros...@suchy.cz > > > > == 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 > > As of today, running %configure or %cmake is part of the %build step, > not the %prep step according to the guidelines. > > Would it mean that we should move this kind of commands in the %prep > step? I think that's technically where they belong. However, focusing > on language stacks won't help for polyglot projects (for example when > using gcc in a Rust project). > Current discussion upstream indicates we'll have a new spec section for generating build dependencies. It'll happen between %prep and %build, most likely. That should not require changing the behavior of how things are done now. > > 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. > > As a mock and RPM user on Fedora, outside of my Fedora endeavors, I > beg to differ ;-) > Yeah, everyone has to update. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On 2/18/19 10:19 PM, Ben Cotton 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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, miros...@suchy.cz == 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. As this change was submitted without prior communication with the primary rpm maintainers, I think a clarification is in order: There needs to be an upstream rpm release with this feature included, we do not do feature backports in Fedora rpm. As of now, this is only being discussed at upstream. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton 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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, > miros...@suchy.cz > > == 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 As of today, running %configure or %cmake is part of the %build step, not the %prep step according to the guidelines. Would it mean that we should move this kind of commands in the %prep step? I think that's technically where they belong. However, focusing on language stacks won't help for polyglot projects (for example when using gcc in a Rust project). > 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. As a mock and RPM user on Fedora, outside of my Fedora endeavors, I beg to differ ;-) > == 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
F31 System-Wide Change proposal: BuildRequires Generators
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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, miros...@suchy.cz == 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-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org 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-announce@lists.fedoraproject.org
F31 System-Wide Change proposal: BuildRequires Generators
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: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, miros...@suchy.cz == 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
