Spec URL: https://www.math.uh.edu/~tibbs/review/fedora-rpm-macros/fedora-rpm-macros.spec SRPM URL: https://www.math.uh.edu/~tibbs/review/fedora-rpm-macros/fedora-rpm-macros-26-1.fc26.src.rpm Description: This package contains the various miscellaneous Fedora-related RPM macros. Fedora Account System Username: tibbs This is a super simple package which currently doesn't actually contain any macros. It will be used as a repository for packaging-committee approved macros so that redhat-rpm-config doesn't have to be modified directly. Notes on rpmlint output: fedora-rpm-macros.noarch: W: no-url-tag The package itself is the upstream. There are very few packages for which this is actually OK, but the various *-rpm-macros packages are all this way. fedora-rpm-macros.noarch: W: only-non-binary-in-usr-lib Things are being installed into %rpmmacrodir (/usr/lib/rpm/macros.d) which is the correct location for this. fedora-rpm-macros.noarch: W: no-documentation Documentation will be in the Fedora packaging guidelines, with explanatory information in the macro file itself. fedora-rpm-macros.src: W: no-url-tag Again, no upstream. fedora-rpm-macros.src: W: strange-permission fedora-rpm-macros.spec 660 fedora-rpm-macros.src: W: strange-permission macros.fedora 660 rpmlint just doesn't like my umask. The buildsystem won't have the same issue. fedora-rpm-macros.src: W: no-%prep-section There's nothing to prep. Nothing to build, either. Otherwise there should be no fedora-review complaints. I have released all copyright to any macros I add, and so the license is Public Domain. Of course, there isn't actually anything at all in this package currently; just one comment.
After thinking about it, epel-rpm-macros is already GPLv2+ and some of the code in these macros will be pretty much identical to those. So I've gone ahead and changed the license for this package to GPLv2+ and reuploaded the spec and srpm.
"various" is "miscellaneous" already. mkdir → just use -D with install. Package is APPROVED :)
Hmm, you're right, -D is a bit shorter, though it does require that you specify the filename. Which means you have to do it twice: once on the Source0: line and once on the install line. I guess its no big deal with just a few files. Currently the line says: install -D -m 644 %{SOURCE0} %{buildroot}/%{_rpmconfigdir}/macros.d/macros.fedora If I'm just not smart enough to figure out how to avoid that, please do let me know. Thanks!
Yeah, install is stupid like that. I don't think the repetition can be avoided.
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/fedora-rpm-macros
(In reply to Jason Tibbitts from comment #0) > This is a super simple package which currently doesn't actually contain any > macros. It will be used as a repository for packaging-committee approved > macros so that redhat-rpm-config doesn't have to be modified directly. Jason, this is very not transparent. Please always post links for FPC decisions about such things! Not everybody (me personally) looks at FPC tickets. My point is that neither from redhat-rpm-config nor from fedora-rpm-config git-log I see where you've been discussing this across fedora board and thus I don't really see _what are the real benefits_ of such package (even though this is probably perfectly valid). Also, what scared me, you've made 'redhat-rpm-config' "Requires: fedora-rpm-macros", so this is basically in every fedora build root. And I see little benefit of having those macros separated, because there is the same "possibility" to break something. It just looks like we are going to have a troubles to get this into CentOS/RHEL/EPEL. What I always disliked about 'redhat-rpm-config' is it's name. That should be named like 'os-rpm-config' --- but that would be about package rename process, not about yet another macro package ... Please make this movement clear, thanks!
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > Yeah, install is stupid like that. I don't think the repetition can be > avoided. There is '--target-directory' option, which should help IMO.
Thanks, this has been an annoying wart. install -Dt /path/to/somewhere/ FILE1 FILE2 should DTRT according to the man page.
I'm sorry, what's not transparent? This is just a package. There's not currently anything actually in it. It's gone through the proper review procedure. It's intended for future use, so we don't keep having to mess with redhat-rpm-config, which is rather more complicated than it needs to be for something that drops in some macro files. Plus it has a rather odd versioning mechanism. This gives me one package I can untag if necessary, without worrying about conflicting with other macro maintenance done by the RPM maintainers. And without using provenpackager privs to get FPC-approved macro work done. Having a package which can hold things like the GPG macros which the packaging committee has been discussing (and which will begin going in as soon as I can find the time) is beneficial. That's the original reason this package was created. I can see no downsides of that. Also note that plenty of other macro packages are now required by redhat-rpm-config. I don't see this trend going away. I also don't see what relevance RHEL/Centos has to this discussion. If EPEL needs these macros for compatibility, they'll go into epel-rpm-macros. If Red Hat wants to follow whatever obviously completely transparent process it has for doing whatever it wants to do internally, then it will and Fedora/EPEL will end up adapting as they always do. That would be no different regardless of where the actual macros are stored. Thanks for the tip about install. It's always bugged me that it doesn't just work like you'd expect by default.
(In reply to Jason Tibbitts from comment #9) > I'm sorry, what's not transparent? This is just a package. That's "just" a package which is always installed in every buildroot. > There's not currently anything actually in it. If there is noting in it, yet - there is no know purpose of the package, and I doubt it is useful to anything. One could consider "empty package" to be the simples "way" to get malicious code into Fedora. WRT your contributions, I know this is not truth - it is simply too early to have it in Fedora now. > It's gone through the proper review procedure. I know, I have no problem with that. Even though I've seen how fast it has been done. > It's intended for future use, so we don't keep having to mess with > redhat-rpm-config, which is rather more complicated than it needs to be for > something that drops in some macro files. Then please drop the requirement from 'redhat-rpm-config' package, so you don't have to consult your changes with FPC. > Plus it has a rather odd versioning mechanism. This gives me one package I > can untag if necessary, without worrying about conflicting with other macro > maintenance done by the RPM maintainers. I understand this argument. But that doesn't mean you need to promote your package that high, it all sounds like some work-around. > And without using provenpackager privs to get FPC-approved macro work done. This is pretty irrelevant. > Having a package which can hold things like the GPG macros which the > packaging committee has been discussing (and which will begin going in as > soon as I can find the time) is beneficial. That's the original reason this > package was created. I can see no downsides of that. Why you feel it is needed to be in every buildroot, however? If that is that important, please put the gpg code into redhat-rpm-config. > Also note that plenty of other macro packages are now required by > redhat-rpm-config. I don't see this trend going away. Well, to some extent (if that is cleverly done enough), it makes sense to add language-specific macro packages, but having 'fedora-rpm-macros' sounds simply like something really replacing redhat-rpm-macros (which in fact provides system-rpm-macros, sounds like way towards rename and something we should call the package now). Every new Requires in redhat-rpm-config should be properly raised on FPC. > I also don't see what relevance RHEL/Centos has to this discussion. If EPEL > needs these macros for compatibility, they'll go into epel-rpm-macros. If > Red Hat wants to follow whatever obviously completely transparent process it > has for doing whatever it wants to do internally, then it will and > Fedora/EPEL will end up adapting as they always do. That would be no > different regardless of where the actual macros are stored. In case the macros are going to be widely used, we would almost certainly go and rename the package (because installing such package in RHEL chroot would just lead to confusion on RHEL). But in such case, you should do your changes directly in redhat-rpm-config. Pavel
Thanks for FPC ticket! https://fedorahosted.org/fpc/ticket/653
What's the status of this? We're starting to see brokenness caused by what I thought was the recommended way of using the GPG macros in the interim: https://bugzilla.redhat.com/show_bug.cgi?id=1404281
(In reply to Jason Tibbitts from comment #9) > I'm sorry, what's not transparent? This is just a package. There's not > currently anything actually in it. It's gone through the proper review > procedure. It's intended for future use, so we don't keep having to mess > with redhat-rpm-config, which is rather more complicated than it needs to be > for something that drops in some macro files. Plus it has a rather odd > versioning mechanism. This gives me one package I can untag if necessary, > without worrying about conflicting with other macro maintenance done by the > RPM maintainers. And without using provenpackager privs to get FPC-approved > macro work done. Um, what? redhat-rpm-config has always been the place to put distro-wide macros in. It *used* to be a crazy mess of patches applied on top of some magic tarball but its trivial to work with now. Yes its versioning is special ... because its a special package, there are no "upstream releases". Distro-wide rpm macro work is something that could maybe use a little bit of review from rpm people, because rpm macros are ... well, I'm sure I dont need to explain that to you. The reason for splitting various language specific items out to different packages is to let the SIGs for those languages work on what they know best and us rpm folks have little to no clue about. It's also possible there are real reasons for creating another macro package for this, but I'm not seeing any of those reasons here, only strange mumbles about redhat-rpm-config maintenance. Moving rpm-related work to another package to basically be able to work behind our back essentially doesn't sound good. Not good at all.