On Thu, 27 Feb 2020 at 17:29, Nils Philippsen <nils@xxxxxxxxxx> wrote: > > On Thu, 2020-02-27 at 15:10 +0100, clime wrote: > > Another thing to consider is whether we want a transparent build > > system where all the description of what will happen when a spec file > > is sent to it is included in the specfile itself or whether we want > > But we don't have that today: think of macros defined externally to the > SPEC file and RPM which we use, think of "underspecified" build > dependencies where what happens to be available and fulfil the BRs will > be used and ultimately influence how the package is built. What happens > when you build a package is already dependent on outside sources. > > > some auto-magic where e.g. 'Release' field or %changelog are > > automatically inserted when missing (something like that is > > impossible > > right now due to rpm constraints but just to make a point). > > Again, this is opt-in. And the way this will be made opt-in is that > people who want to use the feature use a macro, e.g. > "%automatic_release", so that it is clear that some value will be > filled in there. The idea isn't to have gutted spec files that don't > build anywhere else than in our build system, one fixed requirement is > that local builds using fedpkg or rpmbuild must continue to work. Yes, that sounds good! I just wouldn't like too much when a build system would be fiddling with spec files without some explicit macro that everyone can see _in_ the spec file telling it explicitly to do it - like e.g. changing values of some fields that packager manually specified for some reason, e.g. auto correction. > > Nils > -- > Nils Philippsen "Those who would give up Essential Liberty to > Software Engineer purchase a little Temporary Safety, deserve neither > Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 > PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D > old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > _______________________________________________ > 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
