(In reply to comment #0)
> it seems that perl only Provides /usr/bin/perl
Correct.

> well, if ANY package has Require: /bin/perl and is updated the same time as
> perl depsolve in yum fails, you can satifsy such packages only by update the
> packages not at the same time or as i did install a meta-package with
> Provides: /bin/perl which is not true but made it possible to do a
> yum-upgrade on some machines from F16 to F17

My answer to this is quite simple:
* No package must Require: /bin/perl
* Any package requiring /bin/perl has to be considered broken.

Harald, where exactly are these packages requiring /bin/perl? There aren't any in Fedora 17 repos that I can see:

[root@turre ~]# repoquery --enablerepo=updates-testing --whatrequires /bin/perl|wc -l
0
[root@turre ~]# repoquery --enablerepo=updates-testing --whatrequires /usr/bin/perl|wc -l
1218
[root@turre ~]#

My point was that if they are common, there's likely to be a common source for them, but finding the source needs some samples to look at. The case of httpd-devel requiring /bin/perl is an isolated incident from custom-built httpd package in an environment where /bin is before /usr/bin in PATH, which IIRC was caused by openssh having a hard-wired PATH and does not normally happen. If there are other such cases, those need to be looked at case-by-case.

(In reply to comment #2)
> Harald, where exactly are these packages requiring /bin/perl? There aren't
> any in Fedora 17 repos that I can see:
Well, such packages are supposed to fail Auto-QA, because they'd be uninstallable ;)

> My point was that if they are common, there's likely to be a common source
> for them, but finding the source needs some samples to look at. The case of
> httpd-devel requiring /bin/perl is an isolated incident from custom-built
> httpd package in an environment where /bin is before /usr/bin in PATH, which
> IIRC was caused by openssh having a hard-wired PATH and does not normally
> happen. If there are other such cases, those need to be looked at
> case-by-case.

AFAICT, "su" has a similar problem:

[corsepiu@beck ~] echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/users/corsepiu/bin

[corsepiu@beck ~]$ su -l fedora
...
[fedora@beck ~]$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/users/fedora/bin

Note the locations of /bin and /usr/bin.

This causes malfunctions of programs which utilize arg[0] to determine the position of directories they expect to find in a relative position to the program's location (e.g. /usr/bin/foo expects to find ../lib/foodata/).

A real world case for such a package is rpmfusion's m2vmp2cut.

`perl' executable is installed into /usr/bin/perl and thus only `/usr/bin/perl' is provided by perl package. So I cannot put fake /bin/perl into set of Provides.

Despite I agree with you that the usr-move is half-baken, current practise is to install executables into original locations and to let yum to alias the prefixes. I cannot divert one package just for your pleasure. If you insist on your request, please submit an proposal for the change to Fedora Packaging Committee.

ANY package even if rebuilt with "rpmbuild --rebuild" and using perl

yes it is mostly because of the hardcoded PATH in openssh and/or scripts with a /bin/perl-shebang but the rpmbuild maintainers refuse to fix this IMPLICIT Requries while it would be the best point because it is supposed to build packages for fedora AND fedora invented UsrMove

[root@backup-buildserver:~]$ repoquery --whatrequires /bin/perl
httpd-devel-0:2.2.23-7.fc17.20121016.rh.x86_64
mlogc-0:2.6.8-2.fc17.20121016.rh.x86_64
netatalk-4:2.2.4-4.fc17.20121022.rh.x86_64
openssl-perl-1:1.0.0j-2.fc17.20121016.rh.x86_64

Harald, your problem is not perl-specific. Please discuss it at better place.

my real problem is that everyboyd says he is not responsible
however, my workaround is to Provide /bin/perl

[builduser@buildserver:~]$ cat /rpmbuild/SPECS/lounge-base.spec 
Summary:   metapackage for thelounge.net default packages
Name:      lounge-base
Version:   1.6
Release:   1%{?dist}
BuildArch: noarch
Group:     System Environment/Libraries
URL:       http://www.thelounge.net/
License:   GPL
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Provides:  /bin/perl

Requires:  hostname
Requires:  systemd-analyze
Requires:  less
Requires:  rpl
Requires:  bzip2
Requires:  tar

(In reply to comment #7)
> my real problem is that everyboyd says he is not responsible
> however, my workaround is to Provide /bin/perl

Your problem is a build environment with a PATH that's not suitable for Fedora 17. Why dont you fix that instead of trying to work around?

WHY does sshd HARDCODE a PATH not suitable for Fedora?

Well, that's rather obviously an openssh issue, not perl or rpm.