Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=719152 --- Comment #7 from Markus Mayer <LotharLutz@xxxxxx> 2011-10-31 14:16:11 EDT --- (In reply to comment #6) > Thanks for the review! > > (In reply to comment #5) > > NOK[1]: Please use %{buildroot} instead of $RPM_BUILD_ROOT. That is just for > > usabilty as it is easier to read if there is just one macro style used. See > > Package guidelines: "Mixing the two styles, while valid, is bad from a QA and > > usability point of view, and should not be done in Fedora packages." > > You're talking about this: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS > > But I am not mixing the two styles discussed in that section. There is no > instance of either %{buildroot} or %{optflags} in this spec file, therefore > this is a straight $RPM_BUILD_ROOT + $RPM_OPT_FLAGS style. I don't understand > what you are objecting to. > Yes, you are right. I have missinterpreted this section a bit. > > NOK[2]: Can *.v files be considered as header files? As far as I understand > > they more than source files. I think the devel subpackage should be considered > > as "Install this package, if you want to develope a application/library that > > uses the base package". E.g. the devel package for an library written in C only > > contains the header files, because they are required to link the library. If > > someone wants the source files not for developing, but for just looking at it, > > he is required to install the source package. > > The .v files are for human consumption only. They are not necessary for any > computerized task. It is possible to compile applications that use > gappalib-coq without needing the .v files. In that regard, they're kind of > like the various emacs-foo-el packages; nothing in Fedora requires the contents > of those packages, but they are useful for humans to look at. > > If -devel isn't a good name for this subpackage, then how about -source? > > > As Thomas Spura already mentioned on his review for flocq you should consider > > to doing a packaging draft and send it to fpc to clarify this. > > Yes, I will do this. It will probably take me a few days to complete. Thanks. emacs-foo-el packages exists for two reasons (source: http://fedoraproject.org/wiki/Packaging:Emacs): - It is often the case that byte compiling the elisp source for one add-on will require the presence of the elisp source for another add-on package at build time for example. - When debugging a problem with an (X)Emacs package, the Elisp debugger can look up the relevant code or symbol definition in the source lisp file if present. If a user just wants to source to look at it, it is already possible using 'yumdownloader --source packagename'. Maybe this can help you finding your way. Regards, Markus -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review