https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Bug ID: 1366411 Summary: Review Request: fedora-rpm-macros - Miscellaneous Fedora RPM macros Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: tibbs@math.uh.edu QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://www.math.uh.edu/~tibbs/review/fedora-rpm-macros/fedora-rpm-macros.sp... SRPM URL: https://www.math.uh.edu/~tibbs/review/fedora-rpm-macros/fedora-rpm-macros-26... 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #1 from Jason Tibbitts tibbs@math.uh.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |POST CC| |zbyszek@in.waw.pl Assignee|nobody@fedoraproject.org |zbyszek@in.waw.pl Flags| |fedora-review+
--- Comment #2 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- "various" is "miscellaneous" already.
mkdir → just use -D with install.
Package is APPROVED :)
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #3 from Jason Tibbitts tibbs@math.uh.edu --- 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!
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #4 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Yeah, install is stupid like that. I don't think the repetition can be avoided.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #5 from Jason Tibbitts tibbs@math.uh.edu --- Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/fedora-rpm-macros
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Resolution|--- |RAWHIDE Last Closed| |2016-08-12 10:31:28
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Pavel Raiskup praiskup@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |praiskup@redhat.com, | |tibbs@math.uh.edu Flags| |needinfo?(tibbs@math.uh.edu | |)
--- Comment #6 from Pavel Raiskup praiskup@redhat.com --- (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!
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #7 from Pavel Raiskup praiskup@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #8 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Thanks, this has been an annoying wart.
install -Dt /path/to/somewhere/ FILE1 FILE2
should DTRT according to the man page.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tibbs@math.uh.edu | |) |
--- Comment #9 from Jason Tibbitts tibbs@math.uh.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #10 from Pavel Raiskup praiskup@redhat.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
--- Comment #11 from Pavel Raiskup praiskup@redhat.com --- Thanks for FPC ticket! https://fedorahosted.org/fpc/ticket/653
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
David Woodhouse dwmw2@infradead.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dwmw2@infradead.org
--- Comment #12 from David Woodhouse dwmw2@infradead.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
David Woodhouse dwmw2@infradead.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1404281
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1404281 [Bug 1404281] dnf builddep --spec fails to recognize legitimate spec file
https://bugzilla.redhat.com/show_bug.cgi?id=1366411
Panu Matilainen pmatilai@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pmatilai@redhat.com
--- Comment #13 from Panu Matilainen pmatilai@redhat.com --- (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.
package-review@lists.fedoraproject.org