Hello nils! On Wed, 11 Mar 2020 at 16:07, Nils Philippsen <nils@xxxxxxxxxx> wrote: > > On Wed, 2020-03-11 at 12:21 +0100, clime wrote: > > rpmbuild needs to get a preprocessed spec already. > > Hmm, what do you mean with that? I mean, in this proposal, rpmbuild would need to get an already preprocessed spec file on input to work correctly in case the original spec file contains the new macros. I.e. you need to call some other command first (preproc-rpmspec) to get a spec file which is valid by rpm standard. > The spec files we currently have in > dist-git can be built directly with rpmbuild, you just need to tell > rpmbuild that the sources are in the same directory, e.g.: > > --- 8< --- > nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> rpmbuild --define "%_sourcedir $PWD" -ba --clean dcraw.spec Yes, this wouldn't be possible in my proposal iff the spec file contained the new non-rpm syntax. But `fedpkg local` would work or `mock --buildsrpm --spec dcraw.spec --sources .` would work and some tiny wrapper over rpmbuild (e.g. prerpmbuild as mentioned earlier) can be also provided to give users more low-level experience. > setting SOURCE_DATE_EPOCH=1563926400 > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PTKY48 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + cd /home/nils/rpmbuild/BUILD > + rm -rf dcraw > + /usr/bin/gzip -dc /home/nils/dist-git/fedora/rpms/dcraw/dcraw-9.28.0.tar.gz > [... skip build messages ...] > Wrote: /home/nils/rpmbuild/SRPMS/dcraw-9.28.0-6.fc31.src.rpm > Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-debugsource-9.28.0-6.fc31.x86_64.rpm > Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-9.28.0-6.fc31.x86_64.rpm > Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-debuginfo-9.28.0-6.fc31.x86_64.rpm > Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.qq02g8 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + cd dcraw > + /usr/bin/rm -rf /home/nils/rpmbuild/BUILDROOT/dcraw-9.28.0-6.fc31.x86_64 > + RPM_EC=0 > ++ jobs -p > + exit 0 > Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.x7fCS6 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + rm -rf dcraw > + RPM_EC=0 > ++ jobs -p > + exit 0 > nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> > --- >8 --- > > That aside, the main thing I don't like in your proposal is that the > files would still be called '*.spec', but with the additional macros > they wouldn't be RPM spec files anymore. Files which are to be > preprocessed, should be distinguishable from the preprocessed version > by a different extension, e.g.: > > - something.c --> cpp --> something.i > - Makefile.am --> automake --> Makefile.in --> configure --> Makefile > - sendmail.mc -> /etc/mail/make (m4) -> sendmail.cf I understand this and currently, I give my template spec files .spec.rpkg extension (e.g. https://pagure.io/rpkg-util/blob/master/f/rpkg-util.spec.rpkg). But at the same time, I think that calling the file just somepkg.spec would provide a better user experience. Mainly, I wouldn't like very much to break *.spec glob that people might use. I think what is more important is that the glob finds at least something even if it is not necessarily a pure rpm spec file. I can tell you my related personal experience...I used to do web development and at some point, I was seeing all those extensions like .dhtml, .phtml, .html.j2, etc. used for template files. A few years later, however, I started to see a backward trend - some frameworks began to use again just .html even when speaking about dynamic html files. While I was surprised by this initially, in the end, I found it much easier to work with because usually, one just wants to open a template file (when the problem appears to be in a template) and what is the templating language in use is not that important until a file is opened. Best regards! clime > > 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
