On 06/15/2017 10:35 AM, Petr Pisar wrote: > On 2017-06-15, Vít Ondruch <vondruch@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
