https://bugzilla.redhat.com/show_bug.cgi?id=1366411 --- Comment #10 from Pavel Raiskup <praiskup@xxxxxxxxxx> --- (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 -- 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