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). 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). > > --- > > 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? > > Best regards! > clime > > > > > Cheers, > > 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 _______________________________________________ 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
