On Tue, Apr 28, 2020 at 3:40 AM clime <clime@xxxxxxxxxxxxxxxxx> wrote: > > Few more notes: > > I think an idea that build system could be simply passing > --with/--without options on mock's command-line should be > considered...then basically no change in spec files is needed (i.e. no > syntax change). Yes but I'd say such a change would be more complex and invasive. You would still need a place to store these values and make sure the systems (koji, mocks, rpmbuilds on the system, many more) would read the correct configs and pass the values. > It would be great if rpm remembered either the rpmbuild's command-line > in case the solution above is chosen or the set of with options (and > the final values for them) that were used during build if the > buildroot config approach is chosen. I think that would be very useful > for debugging and inspection of rpms. > > ...that's probably it from me. > > clime > > On Tue, 28 Apr 2020 at 03:06, clime <clime@xxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, 27 Apr 2020 at 13:21, Petr Šabata <contyk@xxxxxxxxxx> wrote: > > > > > > Based on the recent discussions around %fedora/%rhel macros and ELN, > > > and %bcond generally being confusing to work with, I came up with a > > > distribution-wide feature that defines generic feature keywords and > > > associated helper macros that packages can check in build-time > > > conditionals. > > > > > > The key advantage here is the defaults are defined by the buildroot, > > > not the package. The package is just a building block. > > > > > > I'd like some input to improve this and unless this turns out to be a > > > really bad idea, I intend to submit it as a change proposal. Even > > > though the more packages use it the more beneficial it gets, it's, of > > > course, perfectly optional. > > > > > > Details in the gist: > > > https://gist.github.com/contyk/0aaaaf0585c57976ca18a293b3566408 > > > > Ad. Dan Mach's presented spec file: > > > > > https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec > > > > I really like how all the switches are defined almost on top of the > > spec file so I think lots of inspiration can be drawn from that. > > > > Now I also think that introduction of the new %use scheme for build > > options instead of the current with/without scheme might be an > > overkill. > > > > I think lines like these: > > > > %bcond_with html > > %bcond_without man > > > > could be replaced by: > > > > %with_option_env html 0 > > %with_option_env man 1 > > > > i.e. %with_option_env <option_name> <default_value> > > > > %with_option_env could be looking at an environmental buildroot > > setting with the possibility to be overridden on command-line by > > --with and --without as usual. > > > > There could be also: > > %with_option <option_name> <default_value> > > > > which wouldn't look at environment settings so it would be the same > > thing as %bcond_with/%bcond_without but less confusing. > > > > So with this, you wouldn't need to change conditions like: > > > > %if %{with foo} > > ... > > %endif > > > > and > > > > %if %{without foo} > > ... > > %endif > > > > ...so fewer changes and less work. I also think these conditions are > > quite fine (except relying on with_foo being either defined or > > undefined, which is quite funky but I don't think it is a reason to > > replace them). I was trying to keep SPEC files as brief as possible. The first time you call any of these macros, the feature is initialized even without any preamble definitions. These are already compatible with --with/--without so you can override the defaults with them. Technically you could do just #%{use foo} in your preamble and then work with %with and %without, which is pretty much what you're suggesting. However, combining the two approaches feels more ugly and confusing to me than sticking to one. > > The yml files and translation from them into the actual macro files > > are nice but I would consider if the hw dependent default values can > > be added in future as a feature. > > > > The local_<pkg>.yml file seems somewhat out of place to me. I think it > > could be rather kept as an idea for future and for now we could just > > start with only buildroot configs? It's a possibility for packages that want or need it. I wouldn't expect many if any local files in the beginning. P _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
