Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 7:40:53 AM CET Jeff Johnson wrote: > If -- as this RFE seems to assume -- you are going to limit the implementation > to "... (Rust, Python, golang) ..." that have alternative non-specfile means > to specify BuildRequires, then all known rpm build systems will require a > change to augment the installed files with newly discovered "dynamic" > BuildRequires. It is up to the build system whether it is going to implement this; the worst case scenario would be to ignore the new format so people won't be allowed to use the feature "because guidelines". > Repopulating a buildroot with additional "dynamic" BuildRequires and > restarting an rpm build either needs to teach rpm how to install additional > packages as a side effect of parsing, or needs to be handled by depsolvers > that populate the buildroot (entirely out of scope for the current rpmbuild > implementation) before rpmbuild is invoked. Agreed. IMO rpm should just speficy "script" which prints build-requires to standard output. That can/could be: %build_requires # the script content /bin/awk ... do something or %build_requires -f or %build_requires -s . this way you don't have to adjust depsolver, only the build-system. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366423220___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 7:18:47 AM CET Jeff Johnson wrote: > Contrarian examples are trivial to devise. Consider an autoconf based > generated file that builds if (and only if) certain files are detected. > None of those BuildRequires can be automated and generated during a spec > file parse with a pipe/file redirection. Understood, but (at least I hope) we aren't trying to find ultimate answer for all packages/languages out there. Some languages try to solve this problem by having list of build requires set upstream, e.g. python: https://packaging.python.org/specifications/declaring-build-dependencies/ We could also think of some heuristic which goes through extracted upstream release tarball, and calculating "what is needed". Packagers would still have %prep for doing `rm` for particular parts of sources which they don't want to build (which is good safety measure anyway, see java packaging practices). > The only solution (I can see) is an attempted build on a system with > "everything" installed that then repeats with the BuildRequires: > detected from the "everything" build. Theoretically yes, but I don't think we have to go that far. Btw. the set of build-requires wouldn't be "constant" for each build of particular package and that would be big -1 from me (at least if you consider bootstrapping scenario where everything isn't completed yet). Whatever the calculated build-requires set would be, I wish it was constant for each build, regardless of what's in buildroot at that time. Maybe I'm missing the point of the issue (OP to decide), but I think this has real and pretty trivial engineering solution for some languages: - distribution provides heuristic for language Foo in foo-build package - package Baz puts 'foo-build' into build requires - package Baz adds "%build_requires --script %foo_analyzer" to declare that the buildsystem should attempt to generate build requires after %prep with %foo_analyzer script - this brings new file/value in generated SRPM to let build-system know - mock finds %build_requires section in SRPM, so it - does installroot + and installs BuildRequires as usually - runs %prep - runs %foo_analyzer from %build_requires - runs the rest of the build In the stack it means: - build system needs an easy way to split build process to two parts (there's --short-circuit, but packages created with this basically aren't installable) - incompatible chnage, so build-systems need to be adjusted -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366422836___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
If -- as this RFE seems to assume -- you are going to limit the implementation to "... (Rust, Python, golang) ..." that have alternative non-specfile means to specify BuildRequires, then all known rpm build systems will require a change to augment the installed files with newly discovered "dynamic" BuildRequires. Repopulating a buildroot with additional "dynamic" BuildRequires and restarting an rpm build either needs to teach rpm how to install additional packages as a side effect of parsing, or needs to be handled by depsolvers that populate the buildroot (entirely out of scope for the current rpmbuild implementation) before rpmbuild is invoked. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366421642___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Contrarian examples are trivial to devise. Consider an autoconf based generated file that builds if (and only if) certain files are detected. None of those BuildRequires can be automated and generated during a spec file parse with a pipe/file redirection. The only solution (I can see) is an attempted build on a system with "everything" installed that then repeats with the BuildRequires: detected from the "everything" build. There is currently no known way other than "works" to verify that the BuildRequires passed to the depsolvers that populates the build system used. Only looping to test that the BuidRequires are sufficient. Hence any attempt to automate BuilRequires *MUST* have a persistent incremental store from which the automagically generated BuildRequires can be retrieved on the final build. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366420520___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 12:08:53 AM CET Jeff Johnson wrote: > @nim-nim: there are classes of BuilRequires: that are not known until after a > build This sounds interesting, don't you have specific example? It rather sounds like bootstrapping issue which the BuildRequires generator isn't supposed to solve. Maybe I finally see what you meant by chicken-egg problem, but this is not what the RFE is about.. > Start designing a collection/query system that can be added to existing > build systems before fiddling around with pipe/file mechanisms and spec > file syntax (the answer will be obvious if you succeed in > capturing/querying BuilRequires). I think I don't really understand what what you propose, how this querying should work? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366418607___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
The real issue is that %changelog carried in *.rpm is mostly useless bloat these days, not how to integrate with other VCS systems, or ChangeLog files. Setup a reliable persistent display of package spec changes, and %changelog will wither away like the human appendix ;-) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/393#issuecomment-366390327___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement fast mode for getting EVR (#392)
Um, spec file parsing is not exactly slow (even with lightly used %include) and there already is a means to query EVR from a spec file. Presumably you are seeking the EVR used on every %changelog entry by brute force: try being more clever, by (say) pickling a store in the git directory incrementally. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/392#issuecomment-366388365___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@nim-nim: there are classes of BuilRequires: that are not known until after a build, so continuing a spec file parse isn't close to an adequate solution, nor does the mechanism (like a pipe instead of a file) or location (like within a *.spec or a *.rpm) make any difference. There is no existing rpm based build system prepared to handle persistent incremental build file generation. Start designing a collection/query system that can be added to existing build systems before fiddling around with pipe/file mechanisms and spec file syntax (the answer will be obvious if you succeed in capturing/querying BuilRequires). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366384693___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Need to update http://rpm.org/about.html (#396)
@leemgs that's in https://github.com/rpm-software-management/rpm-web -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/396#issuecomment-366259411___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Need to update http://rpm.org/about.html (#396)
We need to update some contents of http://rpm.org/about.html. Note that MeeGo was replaced by Tizen in 2012. * before: `http://meego.com/;>Meego` * after: `http://www.tizen.org/;>Tizen` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/396___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
