https://bugzilla.redhat.com/show_bug.cgi?id=1549281 --- Comment #1 from Jason Tibbitts <tibbs@xxxxxxxxxxx> --- So... yeah. I don't want to do this, but someone needs to and I'd rather be on this end of the process than on your end of it. And I apologize in advance, but this is going to be a rambling set of commentary as I look at and test different things. Basically I'm going to take the attitude here that any improvement is just that. If I were more argumentative I would say that this is still not quite the right split, and that we'd all be happier if the four things which have to link against poppler were off on their own or that we should consider a "texlive critpath" which would contain just the things that have to be working in order to build the rest of the distro. But still, this is improvement; this package only has Source347: instead of Source7608: and you really can't argue with that. I'm also going to assume that for tex packaging, the existing texlive package can serve as a "reasonable" (if hilariously enormous) template. The licenses should all be correct (except for "foo"). You will need to add BuildRequires: gcc and probably gcc-c++ so that things will still work once they're pulled from the buildroot (assuming that happens) You can simply %undefine __brp_mangle_shebangs to get rid of that if you don't want it. Though it would be good to know why it's not wanted. You might want to fix the "License: foo" bit (line 23). I see you've done away with the AutoReqProv: lines which all of the -doc subpackages used to have. There are fewer scriptlets than I expected. There is work about to eliminate the need to call install-info, but of course that's not done yet. Without that you'd be down to the fmutil.cnf manipulation. I wonder if there's a better way to handle that, since fmtutil is supposed to handle reading multiple fmtutil.cnf files now. If it could just process a directory inclusion then none of that mess would be necessary. Probably not worth the effort. You can use %_rpmmacrodir instead of defining %macrosdir yourself. If you need EPEL compatibility, let me know and I'll get it in epel-rpm-macros as well. I note that many of the packages have had very significant changes in what they provide. For example, texlive-fontinst (chosen completely at random) went from: tex(bbox.sty) = 2016 tex(cfntinst.sty) = 2016 tex(csc2x.tex) = 2016 tex(csckrn2x.tex) = 2016 tex(finstmsc.sty) = 2016 tex(fontdoc.sty) = 2016 tex(fontinst.sty) = 2016 tex(multislot.sty) = 2016 tex(osf2x.tex) = 2016 tex(xfntinst.sty) = 2016 tex-fontinst = 2016 texlive-fontinst = 6:svn40768-40.fc28.2 to: tex(bbox.sty) = 7:20170520-16.fc29 tex(cfntinst.sty) = 7:20170520-16.fc29 tex(csc2x.tex) = 7:20170520-16.fc29 tex(csckrn2x.tex) = 7:20170520-16.fc29 tex(finstmsc.sty) = 7:20170520-16.fc29 tex(fontdoc.sty) = 7:20170520-16.fc29 tex(fontinst.sty) = 7:20170520-16.fc29 tex(multislot.sty) = 7:20170520-16.fc29 tex(osf2x.tex) = 7:20170520-16.fc29 tex(xfntinst.sty) = 7:20170520-16.fc29 tex-fontinst = 7:20170520-16.fc29 tex-fontinst-bin = 7:20170520-16.fc29 texlive-fontinst = 7:20170520-16.fc29 texlive-fontinst-bin = 7:20170520-16.fc29 texlive-fontinst-doc = 7:20170520-16.fc29 Now, the last five obviously aren't problematic. But I wonder if the others were intentional? The old package uses %tl_version for most of those provides. But in the new pacakge %tl_version is completely absent. %source_date would suffice but the versioning also grew %epoch and %release. I guess the question is whether those were intended to provide semantic data like "2016" or whether the intent was for them to carry the full package version. And looking at this texlive stuff makes me realize (again) that I could generate almost all of the subpackage declarations using RPM macros (with some lua code parsing the texlive.tlpdb file or something like it). This would eliminate the need to have a script generate things separately from the maintenance of the package. Might be an interesting exercise if you would like me to try. Anyway, that's about it for now. In general I don't think there's really anything to object to here, assuming you can stomach the "really huge package" concept. And even if you can't, it's certainly an improvement. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
