In the past, the BuildRequires on perl was not necessary because perl is a dep of rpm-build which is mentioned here:

https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

The comment in the bugzilla that declaring all dependencies "does not violate any rules and does not harm anything" is only somewhat true. The Guidelines express that there is no need to explictly BuildRequire things in the minimal build environment with the note that " they would occur too often". This is not a strong prohibition but was intended to discourage listing them explictly due to adding clutter to the spec file that was seen as unnecessary.

The bugzilla report seems to indicate that perl is no longer in the minimal buildroot, but I can't see why that would be. How was that shown to be the case? It's hinted that lack of BuildRequires: perl is causing mass rebuilds of perl to fail but I'm not sure why that would be the case as long as the dep from rpm-build to perl remains. Are there actual FTBFS issues being caused by this?

Replying to [comment:1 toshio]:

The bugzilla report seems to indicate that perl is no longer in the minimal buildroot, but I can't see why that would be.

I'd guess, they have removed perl from their build-root because they are bootstrapping perl itself from scratch and missed to readd it.

That said, I do not see any reason to mandate BR: perl.
Conversely, I consider BR: perl to be a bug, because it should be BR: %{__perl}.

The whole point is to remove perl from minimal build root (Panu asked for that and I agree that such a huge thing like a perl shouldn't be there). And that clearly shows, that the transitive dependency grant in the guidelines:

There is no need to include the following packages ''or their dependencies'' as !BuildRequires because they would occur too often. These packages are considered the minimum build environment.

is nonsense because it can cause build failures once a package disappears from the build root dependency tree. The transitive rule is ill by definition. I suffer each year with Perl rebuild, because there are people referring to this rule and generalizing it to any dependency and thus causing significant number of build failures (just for example, I have to fix one tenth of all packages this year).

And to be able to remove perl from build root, one has to build-require it in perl packages first. So you can perceive adding the dependency on perl as a preparation for perl removal.

Whether to build-require perl or %{_bindir}/perl is different question. I'd like the latter one, but there are always voices that file-dependencies are wrong (dowloading huge file database), so I use package name instead.

The Ralph's %{!__perl} clashes with guidelines to abandon dummy macros. %{!__perl} is a dummy macro because Fedora does not allow more perl instances. It's the same like %{_rm}. You don't have more rm's or perl's in PATH.

The Parag's categorization as Perl guidelines is not good. This is not specific for Perl. The same applies to any other packages.

Finally, we do not force anybody to build-require perl. We just recommend it.

(BTW, current RT does allow me to CC perl-devel list.

Replying to [comment:3 ppisar]:

The whole point is to remove perl from minimal build root

-1 from me. Perl is not any different from other script languages, so I do not see any reason for this endeavor, may-be except of Red Hat's dislike against perl.

In other words, unless all other script-interpreters are also removed from the build root, this plan is greasy kindergarden to me.

(Panu asked for that and I agree that such a huge thing like a perl shouldn't be there).
The much bigger blob is python.

And that clearly shows, that the transitive dependency grant in the guidelines:

is nonsense because it can cause build failures once a package disappears from the build root dependency tree. The transitive rule is ill by definition. I suffer each year with Perl rebuild,
This doesn't surprise me, because the way you are overengineering things.

Whether to build-require perl or %{_bindir}/perl is different question. I'd like the latter one, but there are always voices that file-dependencies are wrong (dowloading huge file database), so I use package name instead.

The Ralph's
Peter !

%{!__perl} clashes with guidelines to abandon dummy macros. %{!__perl} is a dummy macro because Fedora does not allow more perl instances.

If so, this macros is broken.

Anyway, the behind %{__perl} is to change it globally, e.g. there might be a point in future when Fedora will have perl6 in parallel to perl5 and /usr/bin/perl being a syslink to /usr/bin/perl5, then some time later a symlink to /usr/bin/perl6, the "perl" package being renamed to "perl5" etc.

It's the same like %{_rm}. You don't have more rm's or perl's in PATH.
You can! rm could be a shell built-in!

Finally, we do not force anybody to build-require perl. We just recommend it.
Who is we? The redhat.cz-perl gang? Sorry if I am sounding rude, but IMO, redhat.cz's perl works have reached a point I am seriously pissed off.

Replying to [comment:3 ppisar]:

Whether to build-require perl or %{_bindir}/perl is different question. I'd like the latter one, but there are always voices that file-dependencies are wrong (dowloading huge file database), so I use package name instead.

BR: %{_bindir}/perl does not require huge file metadata download, because base metadata contain all provides from %{_bindir} and %{_sbindir}.

The Parag's categorization as Perl guidelines is not good. This is not specific for Perl. The same applies to any other packages.

Finally, we do not force anybody to build-require perl. We just recommend it.

Please demonstrate a real-world case, preferably with an associated bug report where adding !BuildRequires: perl fixes it. Otherwise I'm -1 on this.

Additionally, I agree with Ralf that the correct place for any guideline change related to this issue is the Perl packaging guidelines.

Replying to [comment:6 rathann]:

Replying to [comment:3 ppisar]:

Whether to build-require perl or %{_bindir}/perl is different question. I'd like the latter one, but there are always voices that file-dependencies are wrong (dowloading huge file database), so I use package name instead.

BR: %{_bindir}/perl does not require huge file metadata download, because base metadata contain all provides from %{_bindir} and %{_sbindir}.

Glad to hear it.

The Parag's categorization as Perl guidelines is not good. This is not specific for Perl. The same applies to any other packages.

Finally, we do not force anybody to build-require perl. We just recommend it.

Please demonstrate a real-world case, preferably with an associated bug report where adding !BuildRequires: perl fixes it.

You know that this problem will emerge once the interpret disappears from minimal build root. Thus you know it's not possible to reproduce it now. But if you want, I will move the Perl dependency generator from rpm-build (as ruby or haskell do) and I will left fixing all the packages up to you on next Perl rebuild. Do you agree?

-- Petr

Looking at this, I think there's two requests here:

1. Handle removing perl from the minimal Buildroot. I had not heard or remembered that this was a thing we wanted to do. Could you post a link to where Panu posts that plan for this ticket? I think there's two ways to accomplish this:
   * We specify that BuildRequires: perl is needed despite perl being part of the minimal BuildRoot specified here: https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 . When perl is dropped as an rpm-build dep packages which haven't converted due to the guideline changes will need to be fixed.
   * We have perl added to the minimal buildroot in koji and removed as a dep from rpm-build and '''do not''' add it to the exceptions list on https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 . Guidelines are changed to mention BR: perl and people need to update their packages. After a release or two, perl is dropped from the minimal buildroot in koji and packages which haven't converted will need to be fixed.
2. Change the minimal buildroot section to be a longer list that explicitly lists all the packages we want in the minimal buildroot and remove the exception for dependencies that are dragged in by the explicit list.
   * From a historical perspective: This was one of the earliest controversial subjects that the FPC had to write a guideline for. IIRC, the current wording was a compromise that suited most of the members at the time. Since it was controversial and it has worked for so long I am reluctant to change it but FPC can certainly revisit it. The FPC membership has changed quite a bit since that decision. From memory, problems with explicitly listing were:
   * The explicit list is long and unwieldy
   * A portion of the members wanted what is actually stated in the guidelines, just with an explicit list instead of the note about following deps. This would have meant that we would be changing the explicit list frequently as the deps changed.

There is a request to remove perl from minimal build root https://bugzilla.redhat.com/show_bug.cgi?id=1158860.

This isn't really an FPC issue, but the issue of completely specifying build dependencies (and not having FPC try to care about what is in the minimal buildroot) is being discussed in https://fedorahosted.org/fpc/ticket/497