= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s): * Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with Perl upstream sources.
== Detailed Description == Upstream releases Perl interpreter together many Perl modules. This set of modules is called core modules. Fedora splits the modules into subpackages so that installing perl package results in stripped-down set of modules. Fedora documents this as a feature and provides perl-core to metapackage that allows installing all the core modules as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this change will rename perl package to perl-interpreter and perl-core package to perl'. This will allow installing all core Perl modules with dnf install perl while still retain the possibility to install only a minimal perl interpreter (/usr/bin/perl) with dnf install perl-interpreter.
This change will also update Fedora Packaging Guidelines for Perl to all spec files that require perl to use perl-interpreter instead. There is only 81 binary packages affected. They will rebuilt. Otherwise no mass rebuild won't be necessary.
To ease sharing spec files with older Fedoras, perl-interpreter provide will add to perl package there.
== Scope == * Proposal owners: - Submit Fedora Packaging Guidelines for Perl update to Fedora Packaging Committee. - Update and rebuild perl source package. - Add Provides: perl-interpreter to perl package in older Fedoras. - Replace BuildRequires and Requires for perl with perl-interpreter in all spec files. - Rebuild packages with replaced Requires to propagate the change to repositories. - Replace perl-core with perl in compose groups definition.
* Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.
* Release engineering: No action needed. Request to check of an impact with Release Engineering: https://pagure.io/releng/issue/6842
* List of deliverables: Anything what contains perl package
* Policies and guidelines: Fedora Packaging Guidelines for Perl update request ( https://pagure.io/packaging-committee/issue/690 ) to use perl and perl-interpreter instead of perl-core and perl.
Trademark approval: N/A (not needed for this Change)
Dne 15.6.2017 v 14:25 Jan Kurik napsal(a):
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
- Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with Perl upstream sources.
== Detailed Description == Upstream releases Perl interpreter together many Perl modules. This set of modules is called core modules. Fedora splits the modules into subpackages so that installing perl package results in stripped-down set of modules. Fedora documents this as a feature and provides perl-core to metapackage that allows installing all the core modules as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this change will rename perl package to perl-interpreter and perl-core package to perl'. This will allow installing all core Perl modules with dnf install perl
The modules will be weak dependencies, i.e. Recommends, right?
Vít
while still retain the possibility to install only a minimal perl interpreter (/usr/bin/perl) with dnf install perl-interpreter.
This change will also update Fedora Packaging Guidelines for Perl to all spec files that require perl to use perl-interpreter instead. There is only 81 binary packages affected. They will rebuilt. Otherwise no mass rebuild won't be necessary.
To ease sharing spec files with older Fedoras, perl-interpreter provide will add to perl package there.
== Scope ==
- Proposal owners:
- Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
- Update and rebuild perl source package.
- Add Provides: perl-interpreter to perl package in older Fedoras.
- Replace BuildRequires and Requires for perl with perl-interpreter in
all spec files.
- Rebuild packages with replaced Requires to propagate the change to
repositories.
- Replace perl-core with perl in compose groups definition.
- Other developers:
Get familiar with new Fedora Packaging Guidelines for Perl.
- Release engineering:
No action needed. Request to check of an impact with Release Engineering: https://pagure.io/releng/issue/6842
- List of deliverables:
Anything what contains perl package
- Policies and guidelines:
Fedora Packaging Guidelines for Perl update request ( https://pagure.io/packaging-committee/issue/690 ) to use perl and perl-interpreter instead of perl-core and perl.
Trademark approval: N/A (not needed for this Change)
On 2017-06-15, Vít Ondruch vondruch@redhat.com wrote:
Dne 15.6.2017 v 14:25 Jan Kurik napsal(a):
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
- Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with Perl upstream sources.
== Detailed Description == Upstream releases Perl interpreter together many Perl modules. This set of modules is called core modules. Fedora splits the modules into subpackages so that installing perl package results in stripped-down set of modules. Fedora documents this as a feature and provides perl-core to metapackage that allows installing all the core modules as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this change will rename perl package to perl-interpreter and perl-core package to perl'. This will allow installing all core Perl modules with dnf install perl
The modules will be weak dependencies, i.e. Recommends, right?
No. The main concern was installing "perl" package does not install all modules. Weakening the dependencies would break this feature. I'd say it's a branding issue. We could maybe in the future cut some modules but because even the users requesting this change were unable to identify them, we will probably keep the full module set there.
Fedora packages will depend on perl-interpreter package or /usr/bin/perl file whose installation won't bring all the modules. There will be no usage for the "perl" package in Fedora package dependency tree. It's more like a comps group. But a package.
-- Petr
On Thu, Jun 15, 2017 at 02:35:59PM +0000, Petr Pisar wrote:
Fedora packages will depend on perl-interpreter package or /usr/bin/perl file whose installation won't bring all the modules. There will be no usage for the "perl" package in Fedora package dependency tree. It's more like a comps group. But a package.
BTW we have a term for that -- a "metapackage".
On 06/15/2017 10:35 AM, Petr Pisar wrote:
On 2017-06-15, Vít Ondruch vondruch@redhat.com wrote:
Dne 15.6.2017 v 14:25 Jan Kurik napsal(a):
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
- Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with Perl upstream sources.
== Detailed Description == Upstream releases Perl interpreter together many Perl modules. This set of modules is called core modules. Fedora splits the modules into subpackages so that installing perl package results in stripped-down set of modules. Fedora documents this as a feature and provides perl-core to metapackage that allows installing all the core modules as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this change will rename perl package to perl-interpreter and perl-core package to perl'. This will allow installing all core Perl modules with dnf install perl
The modules will be weak dependencies, i.e. Recommends, right?
No. The main concern was installing "perl" package does not install all modules. Weakening the dependencies would break this feature. I'd say it's a branding issue. We could maybe in the future cut some modules but because even the users requesting this change were unable to identify them, we will probably keep the full module set there.
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
If your intent is to say unequivocally that this system must not include the perl interpreter unless all of these packages are installed, then that's when you should use Requires:
If instead we want the behavior to be "A user who installs 'perl' gets these packages, but an advanced user can remove the ones they don't actually need later", then "Recommends:" is a better choice.
Fedora packages will depend on perl-interpreter package or /usr/bin/perl file whose installation won't bring all the modules. There will be no usage for the "perl" package in Fedora package dependency tree. It's more like a comps group. But a package.
OK, so this is basically just another way to do what I was suggesting above, just without using the most recent RPM technology. If I understand correctly, you're talking about having a special package named 'perl' that just `Requires: perl-interpreter` and `perl-$MODULES`. So if you did `dnf remove perl-module`, you'd remove the 'perl' package, but not the 'perl-interpreter' package.
If that's the case, I think these two approaches are *basically* identical, except that the metapackage approach will probably cause DNF to misbehave due to the "clean_requirements_on_remove=true" default configuration (which might cause it to try to remove a bunch of other packages that were installed at the same time as 'perl'.
The way I see it, there are benefits and risks to both approaches:
With Recommends: * You don't need to split the 'perl' package to 'perl-interpreter' and the 'perl' metapackage. * Removing individual RPMs doesn't cause the 'perl' package to be removed, so it may be ambiguous at a glance to what degree the system has "perl".
With the metapackage: * You can treat the presence of the 'perl' metapackage as being authoritative about whether the "complete" perl setup is present on the system * Trying to remove individual packages might have complicated interactions.
On Thu, Jun 15, 2017 at 1:27 PM, Stephen Gallagher sgallagh@redhat.com wrote:
If that's the case, I think these two approaches are *basically* identical, except that the metapackage approach will probably cause DNF to misbehave due to the "clean_requirements_on_remove=true" default configuration (which might cause it to try to remove a bunch of other packages that were installed at the same time as 'perl'.
In my opinion, this is merely an example of why the " clean_requirements_on_remove=true" default is problematic. But I won't rehash that discussion here.
-Dan
On 15/06/17 18:27, Stephen Gallagher wrote:
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
Tom
On 06/15/2017 02:02 PM, Tom Hughes wrote:
On 15/06/17 18:27, Stephen Gallagher wrote:
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
You are correct, on upgrade it only updates packages currently on the system. It won't install new ones (except to satisfy new dependencies for existing packages).
So yeah, that's another point in favor of the metapackage approach, I suppose.
On Thursday, 15 June 2017 at 20:05, Stephen Gallagher wrote:
On 06/15/2017 02:02 PM, Tom Hughes wrote:
On 15/06/17 18:27, Stephen Gallagher wrote:
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
You are correct, on upgrade it only updates packages currently on the system. It won't install new ones (except to satisfy new dependencies for existing packages).
No, actually it does try to pull in any missing Recommends:. That's why I have to add -x trousers to every dnf update I do. dnf keeps trying to install it each time.
Regards, Dominik
On 06/15/2017 08:13 PM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 15 June 2017 at 20:05, Stephen Gallagher wrote:
On 06/15/2017 02:02 PM, Tom Hughes wrote:
On 15/06/17 18:27, Stephen Gallagher wrote:
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
You are correct, on upgrade it only updates packages currently on the system. It won't install new ones (except to satisfy new dependencies for existing packages).
No, actually it does try to pull in any missing Recommends:. That's why I have to add -x trousers to every dnf update I do. dnf keeps trying to install it each time.
That's definitely a bug; it's not supposed to be doing that. Have you filed a BZ? (And are you certain that something else isn't trying to Requires: it?)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Fri, 2017-06-16 at 02:13 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 15 June 2017 at 20:05, Stephen Gallagher wrote:
On 06/15/2017 02:02 PM, Tom Hughes wrote:
On 15/06/17 18:27, Stephen Gallagher wrote:
I think you may misunderstand what "Recommends" means. At install-time, it will still be pulled into the system as if it was a "Requires:". The difference is that if someone later decides to do 'dnf remove perl-foo', it can be removed without also removing the main 'perl' package (which is what would happen if it is a full "requires").
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
You are correct, on upgrade it only updates packages currently on the system. It won't install new ones (except to satisfy new dependencies for existing packages).
No, actually it does try to pull in any missing Recommends:. That's why I have to add -x trousers to every dnf update I do. dnf keeps trying to install it each time.
mlschroe commented on Dec 12, 2016
Ah, it's a feature. Anyway, it's pretty impossible to fix.
The problem is that there is no information why bash-completion is not installed. Is it because it was not available in the repos before? Or it was not installable because some other installed packages conflicted with it? Or some dependency could not be met at the time? Or the user installed dnf with weak deps disabled? Or it was installed and got deinstalled?
So we simply don't know what the reason is. Just ignoring the Recommends is as wrong as installing it. Add the package to your exclude list if you don't want to have it installed. (Or disfavor list at some point in dnf's future...)
This is possible to fix on DNF's end, but it is complicated to implement. So if you really want to have minimal system, set install_weak_deps=false in dnf.conf and use -- setopt=install_weak_deps=true when installing packages.
Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
- -- - -Igor Gnatenko
On Fri, Jun 16, 2017 at 03:35:46PM +0200, Igor Gnatenko wrote:
What does "Recommends" do on upgrade?
In other words if Recommends was used and a new perl version had new modules in the core package would an upgrade of perl pull them in as you would expect?
I don't see how it can unless it also reinstalls ones the user had chosen to remove?
You are correct, on upgrade it only updates packages currently on the system. It won't install new ones (except to satisfy new dependencies for existing packages).
No, actually it does try to pull in any missing Recommends:. That's why I have to add -x trousers to every dnf update I do. dnf keeps trying to install it each time.
Ah, it's a feature. Anyway, it's pretty impossible to fix.
The problem is that there is no information why bash-completion is not installed. Is it because it was not available in the repos before? Or it was not installable because some other installed packages conflicted with it? Or some dependency could not be met at the time? Or the user installed dnf with weak deps disabled? Or it was installed and got deinstalled?
So we simply don't know what the reason is. Just ignoring the Recommends is as wrong as installing it. Add the package to your exclude list if you don't want to have it installed. (Or disfavor list at some point in dnf's future...)
This is possible to fix on DNF's end, but it is complicated to implement. So if you really want to have minimal system, set install_weak_deps=false in dnf.conf and use -- setopt=install_weak_deps=true when installing packages.
Incidentally, with deb packages, the package database retains knowledge of uninstalled packages. I'd wondered why that was, but purhaps it's used for cases like this. If that's the case, it doesn't seem all that difficult for RPM (or DNF) to do the same.
On Thu, Jun 15, 2017 at 2:06 PM, Emmanuel Seyman emmanuel@seyman.fr wrote:
- Stephen Gallagher [15/06/2017 13:27] :
If your intent is to say unequivocally that this system must not include
the
perl interpreter unless all of these packages are installed, then that's
when
you should use Requires:
This is what upstream is requesting.
Not exactly; the request is that if the package named "perl" is installed, then the system should have all of the core modules installed.
-Dan
On 06/15/2017 02:14 PM, Dan Book wrote:
On Thu, Jun 15, 2017 at 2:06 PM, Emmanuel Seyman <emmanuel@seyman.fr mailto:emmanuel@seyman.fr> wrote:
* Stephen Gallagher [15/06/2017 13:27] : > > If your intent is to say unequivocally that this system must not include the > perl interpreter unless all of these packages are installed, then that's when > you should use Requires: This is what upstream is requesting.Not exactly; the request is that if the package named "perl" is installed, then the system should have all of the core modules installed.
Right, with that in mind, it sounds like the "perl metapackage" approach is the most in line with what upstream is doing as well as leaving the door open for Fedora to minimize things for constrained uses (like a cloud image).
On Thu, 2017-06-15 at 14:35 +0000, Petr Pisar wrote:
this change is breaking builds on EPEL7 [1] DEBUG util.py:450: Error: No Package found for perl-interpreter DEBUG util.py:450: Error: No Package found for perl-interpreter
Any advice is welcome .
Thanks, [1] https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/... https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/... https://copr.fedorainfracloud.org/coprs/sergiomb/debs/build/590775/
On Wed, Aug 16, 2017 at 7:55 AM, Sérgio Basto sergio@serjux.com wrote:
On Thu, 2017-06-15 at 14:35 +0000, Petr Pisar wrote:
this change is breaking builds on EPEL7 [1] DEBUG util.py:450: Error: No Package found for perl-interpreter DEBUG util.py:450: Error: No Package found for perl-interpreter
Any advice is welcome .
Thanks, [1] https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/... https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/... https://copr.fedorainfracloud.org/coprs/sergiomb/debs/build/590775/
Just guard it out:
%if 0%{?rhel} && 0%{?rhel} < 8 BuildRequires: perl %else BuildRequires: perl-interpreter %endif
On Wed, Aug 16, 2017 at 12:55:14PM +0100, Sérgio Basto wrote:
this change is breaking builds on EPEL7 [1] DEBUG util.py:450: Error: No Package found for perl-interpreter DEBUG util.py:450: Error: No Package found for perl-interpreter
Yes, because it's a Fedora change. Not EPEL one.
Any advice is welcome .
Many options:
(1) Do not merge master to epel7. Skip the one commit that renamed the dependency in master.
(2) Make the dependency conditional as suggested by Neal.
(3) Buy a RHEL-7 subscription and escalate your issue to Red Hat support to implement bug #1410347.
(4) I could add a sub-package to perl-generators that already exists in EPEL7 so that perl-interpreter can be satisfied in EPEL7.
I consider the last option the most dirty, but I will do it because this is the cheapest solution.
-- Petr
On Wed, 2017-08-16 at 14:38 +0200, Petr Pisar wrote:
On Wed, Aug 16, 2017 at 12:55:14PM +0100, Sérgio Basto wrote:
this change is breaking builds on EPEL7 [1] DEBUG util.py:450: Error: No Package found for perl-interpreter DEBUG util.py:450: Error: No Package found for perl-interpreter
Yes, because it's a Fedora change. Not EPEL one.
Any advice is welcome .
Many options:
(1) Do not merge master to epel7. Skip the one commit that renamed the dependency in master.
(2) Make the dependency conditional as suggested by Neal.
(3) Buy a RHEL-7 subscription and escalate your issue to Red Hat support to implement bug #1410347.
Many thanks Peter, I think this one (without buying RHEL-7 subscription ) is the best one . I already add my vote in https://bugzilla.redhat.com/show_bug.cgi?id=1410347
(4) I could add a sub-package to perl-generators that already exists in EPEL7 so that perl-interpreter can be satisfied in EPEL7.
I consider the last option the most dirty, but I will do it because this is the cheapest solution.
-- Petr _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Aug 16, 2017 at 8:49 AM, Sérgio Basto sergio@serjux.com wrote:
On Wed, 2017-08-16 at 14:38 +0200, Petr Pisar wrote:
On Wed, Aug 16, 2017 at 12:55:14PM +0100, Sérgio Basto wrote:
this change is breaking builds on EPEL7 [1] DEBUG util.py:450: Error: No Package found for perl-interpreter DEBUG util.py:450: Error: No Package found for perl-interpreter
Yes, because it's a Fedora change. Not EPEL one.
Any advice is welcome .
Many options:
(1) Do not merge master to epel7. Skip the one commit that renamed the dependency in master.
(2) Make the dependency conditional as suggested by Neal.
(3) Buy a RHEL-7 subscription and escalate your issue to Red Hat support to implement bug #1410347.
Many thanks Peter, I think this one (without buying RHEL-7 subscription ) is the best one . I already add my vote in https://bugzilla.redhat.com/show_bug.cgi?id=1410347
I'll point out that if you are waiting for that fix to land in RHEL, you will be waiting a long time. RHEL 7.4 was just released a couple weeks ago. The next time a change like that would land in RHEL is RHEL 7.5, which will not be for months at a minimum. And that's only *if* it gets accepted.
You probably want to use one of the other solutions.
josh
On 2017-06-15, Jan Kurik jkurik@redhat.com wrote:
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Because all Fedora branches recognize perl-interpreter dependency now I will start renaming the dependency in all affected packages. There will be two rounds:
(1) I will rename BuildRequires in 2300 spec files. The only change will be the rename. Not Release bump. The commit message will be "perl dependency renamed to perl-interpreter https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules".
(2) I will rename Requires (and BuildRequires where presented) in another 74 packages. These will receive Release bump and they will be rebuilt in Koji. Everything in one commit with the same commit message. (The 75th package is "kernel" that will receive only the rename. No release bump, no rebuild.)
Then I will rename binary perl package to perl-interpreter in perl.spec and rebuild perl. This will effectively materialize the goal of this change.
After few days, I will recheck existence of perl dependencies in source packages and correct them. There is an inevitable window beteen gathering the package list and applying the changes, thus it's possible that some packages slip.
-- Petr
On 2017-07-12, Petr Pisar ppisar@redhat.com wrote:
On 2017-06-15, Jan Kurik jkurik@redhat.com wrote:
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Because all Fedora branches recognize perl-interpreter dependency now I will start renaming the dependency in all affected packages. There will be two rounds:
(1) I will rename BuildRequires in 2300 spec files. The only change will be the rename. Not Release bump. The commit message will be "perl dependency renamed to perl-interpreter https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules".
This was completed yesterday.
(2) I will rename Requires (and BuildRequires where presented) in another 74 packages. These will receive Release bump and they will be rebuilt in Koji. Everything in one commit with the same commit message. (The 75th package is "kernel" that will receive only the rename. No release bump, no rebuild.)
This is almost done. Few packages failed to rebuild due to other reasons. I will file bugs and possibly try fixing them.
Then I will rename binary perl package to perl-interpreter in perl.spec and rebuild perl. This will effectively materialize the goal of this change.
I'm going to do this tomorrow.
You can consider the mass rename having been finished.
-- Petr
On 2017-06-15, Jan Kurik jkurik@redhat.com wrote:
= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
- Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with Perl upstream sources.
This change has been implemented in perl-5.26.0-395.fc27.
-- Petr
devel@lists.stg.fedoraproject.org
-
Dan Book -
Dominik 'Rathann' Mierzejewski -
Emmanuel Seyman -
Igor Gnatenko -
Jan Kurik -
Josh Boyer -
Matthew Miller -
Neal Gompa -
Petr Pisar -
Scott Schmit -
Stephen Gallagher -
Sérgio Basto -
Tom Hughes -
Vít Ondruch