On Thu, 30 Apr 2020 at 10:40, Petr Šabata <contyk@xxxxxxxxxx> wrote:
>
> 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.
Well, in the end, it would probably mean rpmbuild would have a new
option to consume build-config.yml with all the with/withouts, which
would be cool because the config could be serialized in its headers -
at least for those options that were actually used from the spec file.
A disadvantage is that bare/default rpmbuild would be using spec
defined defaults for the with options so you would need to add the new
--build-config option explicitly on command-line to actually build the
same rpms that are being built in mock or a build system (both could
do that by default). This seems quite alright to me, nevertheless. I
like that the method to influence a build is explicit and the config
can be imprinted into the built rpms. I think this will be otherwise a
problem if the .yml configs are translated into system-wide rpm
macros.
> 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.
I was rather suggesting using just a dedicated %with related preamble like:
%wIth_option_env to explicitly state: "hey, I am taking something from
the environment here."
It would give you a quick list in spec file what you can configure,
which is nice.
Anyway, it's quite hard to image %use and %with to co-exist. Ability
to affect %use by --with/--without options seems confusing so while I
like this initiative, it probably tries to change more than is really
required to change. Idk, I don't really have a strong opinion here. I
am glad you have built a cool prototype and showed it to the community
for review. I think that's an important thing here.
clime
>
>
> > > 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
_______________________________________________
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
