Re: perl @INC (paths) again
On Wed, Feb 02, 2011 at 10:43:10AM +, Paul Howarth wrote: However, the plan envisages third-party repositories sticking with vendor directories and I'm not sure that's going to happen. If I need a module for my own repository and Fedora already has some version of it, I just grab that version, update it as necessary and built it. So I'll inherit the use of the perl/core directories unless I explicitly revert back to vendor directories. Other repositories might also want to maintain as close compatibility with Fedora as possible and would use that as justification for using perl/core too. We should not assume anything about third-party repositories. Neither how they write their spec files (if any), nor if they are compatible. This is the reason why I think reserving a directory just for that purpose is good idea. Third party (= not provided by Fedora) modules should be allowed to do what they wish and distribution should not create obstacles. I think it's better to make Fedora more versatile than to burden developers of unoffical distribution extenstions. I thought the conventional structure of having modules bundled with perl (the perl core) going to perl/core directories and everything else that's packaged (including dual lived modules) going to vendor directories made good, intuitive sense, and I think that's what upstream intended too. Dual-lived modules. That's another problem: Having them in the same directory as core modules allows packager to discover clashes sooner than at run time because RPM warns you that new package tries to overwrite file owned by another package. Also administrator gets sure there is no remaining code from original module. This is especially important when fixing security bugs. On the other hand, RPM has problem with architecture specific dual-lived packages. The problem is debuging data for all sub-packages are distributed in one package. Thus once you install perl-debuginfo, you cannot install debuginfo for dual-lived package because the files are stored in the same paths. See https://bugzilla.redhat.com/show_bug.cgi?id=664414 for more details. Installing dual-lived modules into separate paths works around this problem. So, I like the idea to clean include paths and have everything on one place. However I'm worried Fedora packaging system is not prepared for it yet. -- Petr pgpliy6dJoANA.pgp Description: PGP signature -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
* Iain Arnell [03/02/2011 09:31] : I agree. Marcela's proposal is fine in principle, but unlikely to achieve much in practice. I have to admit this is my conclusion as well. On Wed, Feb 2, 2011 at 11:43 AM, Paul Howarth p...@city-fan.org wrote: So overall I'm in favour of using the F-15 set of paths (assuming the typos are fixed) but sticking with the vendor directories for everything apart from the perl core. +1 to that. Add my +1 to the list. Emmanuel -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 02/07/2011 11:43 PM, Emmanuel Seyman wrote: * Iain Arnell [03/02/2011 09:31] : I agree. Marcela's proposal is fine in principle, but unlikely to achieve much in practice. I have to admit this is my conclusion as well. On Wed, Feb 2, 2011 at 11:43 AM, Paul Howarthp...@city-fan.org wrote: So overall I'm in favour of using the F-15 set of paths (assuming the typos are fixed) but sticking with the vendor directories for everything apart from the perl core. +1 to that. Add my +1 to the list. Then you are likely able to explain why you want to see this implemented? I fail to see _any_ advantage this approach provides, but consider it to provide only regressons what Fedora 14 had. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 02/02/2011 11:43 AM, Paul Howarth wrote:
On 31/01/11 15:21, Marcela Mašláňová wrote:
Hello,
because some questions and blocked reviews [1]. I feel that we really
need discuss our @INC paths once again. I wrote proposal, which is
almost the same as was the one sent to the list few months ago [2].
This is only proposal and there are also other possibilities, how to
create specific directory for installation of users rpms. I'd like to
change this proposal to FPC guidelines maybe for next Fedora, therefore
I really like to know your opinions.
First of all, what are presumably typos:
F-15:
@INC:
/usr/local/lib/perl5 -- for CPAN (site lib)
/usr/local/share/perl5 -- for CPAN (site arch)
/usr/lib/perl5/vendor_perl -- 3rd party(vendor lib)
/usr/share/perl5/vendor_perl -- 3rd party(vendor arch)
/usr/lib/perl5 -- Fedora (priv lib)
/usr/share/perl5 -- Fedora (arch lib)
.
Should surely be:
@INC:
/usr/local/%{_lib}/perl5 -- for CPAN (site arch)
/usr/local/share/perl5 -- for CPAN (site lib)
%{_libdir}/perl5/vendor_perl -- 3rd party(vendor arch)
/usr/share/perl5/vendor_perl -- 3rd party(vendor lib)
%{_libdir}/perl5 -- Fedora (arch lib)
/usr/share/perl5 -- Fedora (priv lib)
.
I don't really see any great harm in installing modules to perl/core
directories rather than vendor directories. I also like this nice,
simple set of paths.
However, the plan envisages third-party repositories sticking with
vendor directories and I'm not sure that's going to happen.
Actually I have never seen anybody doing this.
Apart of this this definition of vendor_dir
- Does not match Fedora's practice to install into vendor_dir.
- Violates the FHS. 3rd party's are supposed to install to /opt.
I thought the conventional structure of having modules bundled with perl
(the perl core) going to perl/core directories and everything else
that's packaged (including dual lived modules) going to vendor
directories made good, intuitive sense, and I think that's what upstream
intended too.
Agreed.
Moreover, it seems to be widespread policy elsewhere:
https://wiki.archlinux.org/index.php/Perl_Policy
http://use.perl.org/~schwern/journal/39246
https://www.socialtext.net/perl5/index.cgi?hints_for_distributors
http://www.debian.org/doc/packaging-manuals/perl-policy/
So overall I'm in favour of using the F-15 set of paths (assuming the
typos are fixed) but sticking with the vendor directories for everything
apart from the perl core.
Well, IMO
a) these F15 paths are a regression in comparsion to what Fedora15 had
because they reintroduce vendor_dir.
b) these F15 paths break with Fedora's convention to use vendor_dir to
install Fedora-modules = This proposal would requires inspecting all
perl-module's specs and rebuild them.
c) the setting for vendor_dir is a broken as were its predecessors
(letting the site*dir point to user local makes sense).
I.e. if this convention shall be applied, we need to modifiy and rebuild
all perl-packages which currently install to vendor_dir.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 02/01/2011 05:09 PM, Ralf Corsepius wrote: On 01/31/2011 04:36 PM, Ralf Corsepius wrote: On 01/31/2011 04:21 PM, Marcela Mašláňová wrote: Hello, because some questions and blocked reviews [1]. I feel that we really need discuss our @INC paths once again. Thanks for trying to launch such a discussion. I am blocking these reviews, because I feel redhat.cz has drawn uncommunicated, arguable and questionable decisions, which are at risk of to run down Fedora's perl. This is only proposal and there are also other possibilities, how to create specific directory for installation of users rpms. I'd like to change this proposal to FPC guidelines maybe for next Fedora, therefore I really like to know your opinions. I promise to read it in depth and to think about it, but I won't have much time this week. Marcela, what are we supposed to think of the fact you are continuing to accept packages which do not install into vendor_dir? I interpret these actions of yours, as you not being interested in settling the issues, but you wanting to implement facts by brute-force. This is not helpful. Reviews like this https://bugzilla.redhat.com/show_bug.cgi?id=664817 are also not helpful. Ok, I'll be doing nothing until some decision ;-) -- Marcela Mašláňová BaseOS team Brno -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 31/01/11 15:21, Marcela Mašláňová wrote:
Hello,
because some questions and blocked reviews [1]. I feel that we really
need discuss our @INC paths once again. I wrote proposal, which is
almost the same as was the one sent to the list few months ago [2].
This is only proposal and there are also other possibilities, how to
create specific directory for installation of users rpms. I'd like to
change this proposal to FPC guidelines maybe for next Fedora, therefore
I really like to know your opinions.
First of all, what are presumably typos:
F-15:
@INC:
/usr/local/lib/perl5-- for CPAN (site lib)
/usr/local/share/perl5 -- for CPAN (site arch)
/usr/lib/perl5/vendor_perl -- 3rd party(vendor lib)
/usr/share/perl5/vendor_perl-- 3rd party(vendor arch)
/usr/lib/perl5 -- Fedora (priv lib)
/usr/share/perl5-- Fedora (arch lib)
.
Should surely be:
@INC:
/usr/local/%{_lib}/perl5-- for CPAN (site arch)
/usr/local/share/perl5 -- for CPAN (site lib)
%{_libdir}/perl5/vendor_perl-- 3rd party(vendor arch)
/usr/share/perl5/vendor_perl-- 3rd party(vendor lib)
%{_libdir}/perl5-- Fedora (arch lib)
/usr/share/perl5-- Fedora (priv lib)
.
I don't really see any great harm in installing modules to perl/core
directories rather than vendor directories. I also like this nice,
simple set of paths.
However, the plan envisages third-party repositories sticking with
vendor directories and I'm not sure that's going to happen. If I need a
module for my own repository and Fedora already has some version of it,
I just grab that version, update it as necessary and built it. So I'll
inherit the use of the perl/core directories unless I explicitly revert
back to vendor directories. Other repositories might also want to
maintain as close compatibility with Fedora as possible and would use
that as justification for using perl/core too.
I thought the conventional structure of having modules bundled with perl
(the perl core) going to perl/core directories and everything else
that's packaged (including dual lived modules) going to vendor
directories made good, intuitive sense, and I think that's what upstream
intended too. Moreover, it seems to be widespread policy elsewhere:
https://wiki.archlinux.org/index.php/Perl_Policy
http://use.perl.org/~schwern/journal/39246
https://www.socialtext.net/perl5/index.cgi?hints_for_distributors
http://www.debian.org/doc/packaging-manuals/perl-policy/
So overall I'm in favour of using the F-15 set of paths (assuming the
typos are fixed) but sticking with the vendor directories for everything
apart from the perl core.
Paul.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On Wed, Feb 2, 2011 at 11:43 AM, Paul Howarth p...@city-fan.org wrote: [snip] I don't really see any great harm in installing modules to perl/core directories rather than vendor directories. I also like this nice, simple set of paths. However, the plan envisages third-party repositories sticking with vendor directories and I'm not sure that's going to happen. If I need a module for my own repository and Fedora already has some version of it, I just grab that version, update it as necessary and built it. So I'll inherit the use of the perl/core directories unless I explicitly revert back to vendor directories. Other repositories might also want to maintain as close compatibility with Fedora as possible and would use that as justification for using perl/core too. I agree. Marcela's proposal is fine in principle, but unlikely to achieve much in practice. There are also tools like cpanspec to consider: presumably we'll want our cpanspec to use perl/core directories by default, so anyone else using it for packaging will end up doing the same as well. I thought the conventional structure of having modules bundled with perl (the perl core) going to perl/core directories and everything else that's packaged (including dual lived modules) going to vendor directories made good, intuitive sense, and I think that's what upstream intended too. Moreover, it seems to be widespread policy elsewhere: I really don't see a good reason for users/3rd parties to need to install RPMs using a different path. The only conceivable reason I can think of would be to override a dual-life part-of-perl-rpm core module with a newer version; but even in that case, I'd much rather see the module split into a sub-package so that it can be replaced as normal by a newer RPM using vendor dirs. So overall I'm in favour of using the F-15 set of paths (assuming the typos are fixed) but sticking with the vendor directories for everything apart from the perl core. +1 to that. -- Iain. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 01/31/2011 04:36 PM, Ralf Corsepius wrote: On 01/31/2011 04:21 PM, Marcela Mašláňová wrote: Hello, because some questions and blocked reviews [1]. I feel that we really need discuss our @INC paths once again. Thanks for trying to launch such a discussion. I am blocking these reviews, because I feel redhat.cz has drawn uncommunicated, arguable and questionable decisions, which are at risk of to run down Fedora's perl. This is only proposal and there are also other possibilities, how to create specific directory for installation of users rpms. I'd like to change this proposal to FPC guidelines maybe for next Fedora, therefore I really like to know your opinions. I promise to read it in depth and to think about it, but I won't have much time this week. Marcela, what are we supposed to think of the fact you are continuing to accept packages which do not install into vendor_dir? I interpret these actions of yours, as you not being interested in settling the issues, but you wanting to implement facts by brute-force. This is not helpful. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 01/31/2011 04:21 PM, Marcela Mašláňová wrote: Hello, because some questions and blocked reviews [1]. I feel that we really need discuss our @INC paths once again. Thanks for trying to launch such a discussion. I am blocking these reviews, because I feel redhat.cz has drawn uncommunicated, arguable and questionable decisions, which are at risk of to run down Fedora's perl. This is only proposal and there are also other possibilities, how to create specific directory for installation of users rpms. I'd like to change this proposal to FPC guidelines maybe for next Fedora, therefore I really like to know your opinions. I promise to read it in depth and to think about it, but I won't have much time this week. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
* Marcela Mašláňová [31/01/2011 16:57] : This is only proposal and there are also other possibilities, how to create specific directory for installation of users rpms. I'd like to change this proposal to FPC guidelines maybe for next Fedora, therefore I really like to know your opinions. I'll read it this week and submit any feedback I have. Emmanuel -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
