Bug 73970 - perl rpm should create and own Bundle, auto and vendor_perl directories
perl rpm should create and own Bundle, auto and vendor_perl directories
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
David Lawrence
:
Depends On: 89740
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-13 12:17 EDT by Gary Benson
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 16:05:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Own "auto" dirs (477 bytes, patch)
2003-07-29 12:45 EDT, Ville Skyttä
no flags Details | Diff
Own site/vendor auto dirs (UTF-8, gzipped for i18n reasons) (594 bytes, application/octet-stream)
2003-12-07 04:53 EST, Ville Skyttä
no flags Details

  None (edit)
Description Gary Benson 2002-09-13 12:17:33 EDT
Description of Problem:
The various Bundle and auto directories are currently created and destroyed by
perl module rpms on an ad-hoc basis, which causes problems as described in the
comments to bug 73935.  A nice fix to this would be to make the perl rpm create
and own all auto and Bundle directories and to fix the other
packages that claim to own them (perl-DBI, perl-DBD-MySQL and perl-DBD-Pg).
Comment 1 Enrico Scholz 2003-05-02 08:09:17 EDT
This will not work because the erase-order can not be defined in current rpm.
E.g. when you have 'perl' and 'perl-foo', 'perl' can be removed before
'perl-foo' although 'perl' is a requirement of 'perl-foo'.

Further comments can be found in bug #89740 and a demonstration at
http://www.tu-chemnitz.de/~ensc/A.spec.
Comment 2 Enrico Scholz 2003-05-06 13:27:20 EDT
Because 'auto' directories are at a few, specific positions, these should be
owned by perl. I do not know, when/if rpm will be fixed but I can live with some
orphaned ../perl5/.../auto directories.

But there are too much Bundle (or other perl-classes) packages that perl could
own them all, and the subdir-ownership/dependence (perl-X owns .../perl5/X,
perl-X-Y owns .../perl5/X/Y and requires perl-X) does not work because of rpm
brokeness.
Comment 3 Ville Skyttä 2003-07-29 12:45:03 EDT
Created attachment 93227 [details]
Own "auto" dirs

The patch could look something like this (against perl-5.8.1-90.rc2.1,
untested).  Dunno whether %{multilib_64_archs} need something in addition.
Comment 4 Nils Philippsen 2003-10-16 12:59:45 EDT
Apparently still the case with FC test3 -- this is currently worked around in
several packages, but not everything "get's caught":

nils@wombat:~> rpm -qf $(find /usr/lib/perl5/{5.8.1,{vendor,site}_perl} -name
Bundle -o -name auto|grep -v 5.6)
perl-5.8.1-92
perl-5.8.1-92
file /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto is not owned
by any package
file /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Bundle is not
owned by any package
file /usr/lib/perl5/vendor_perl/5.8.0/Bundle is not owned by any package
file /usr/lib/perl5/vendor_perl/5.8.0/auto is not owned by any package
file /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi-stdio/auto is not
owned by any package
file /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi/Bundle is not
owned by any package
perl-NKF-2.03-1
gaim-0.71-0
file /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto is not owned by
any package
file /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/auto is not owned by
any package
Comment 5 Enrico Scholz 2003-10-23 09:08:05 EDT
Yes, there has not been changed very much: nearly all perl-packages are
producing orphaned directories (inclusive '.../auto'):

http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/severn3.html.gz
Comment 6 Ville Skyttä 2003-11-30 08:05:00 EST
This issue still exists in FC1.

(I tried to change the version to "1" and summary to "perl rpm should
create and own Bundle, auto and vendor_perl directories" but wasn't
permitted to do that.)
Comment 7 Nils Philippsen 2003-11-30 12:42:23 EST
If all goes well, I should be able to change version and summary.
Comment 8 Ville Skyttä 2003-12-07 04:53:03 EST
Created attachment 96388 [details]
Own site/vendor auto dirs (UTF-8, gzipped for i18n reasons)

This issue still exists in 5.8.2-2 in rawhide.	I believe the attached specfile
patch fixes it correctly, please apply.

Oh, and IMO "Bundle" directories should not be owned by the perl package, but
the relevant Bundle-* packages instead.
Comment 9 Warren Togami 2005-04-25 20:39:43 EDT
Is this still an issue?
Comment 10 Gary Benson 2005-04-26 04:42:08 EDT
Looks like there's still some gaps:

$ rpm -qf $(find /usr/lib/perl5/{5.8.1,{vendor,site}_perl} -name Bundle -o -name
auto) | grep "not owned"
file /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/Bundle is not
owned by any package
file /usr/lib/perl5/vendor_perl/5.8.5/Bundle is not owned by any package
Comment 11 Ville Skyttä 2005-04-26 10:09:45 EDT
As said in comment 8, I don't think the perl package should own the "Bundle"
directories unless it installs something into them itself.  They should be owned
by the package(s) that create them, just like all other module packages out
there own the dirs of their CPAN namespace.  

Based on quick inspection on my FC3 and Rawhide boxes, it seems that the
respective module packages (perl-DBI, perl-DBD-MySQL, mod_perl and
perl-libwww-perl) have already been fixed to take ownership of the Bundle dirs
they install stuff into.

The "auto" dirs are a separate beast, they're not part of a CPAN namespace so
it's good to have the main perl package own them.

Unless I'm missing something, as far as I'm concerned, this has been resolved
already for a while.
Comment 12 Warren Togami 2005-04-26 16:05:57 EDT
OK, based upon Ville's comment closing.  If you have issue with this please
discussion it on fedora-perl-devel-list.

Note You need to log in before you can comment on or make changes to this bug.