4:34 a.m.
Hi,
Do we need to split out this dep from perl in RPM spec? Someone says
it's needed and someone doesn't support this idea.
Thanks.
Yours sincerely,
Christopher Meng
Always playing in Fedora Project
http://cicku.me
9:06 p.m.
On Wed, Jul 3, 2013 at 2:34 AM, Christopher Meng <cickumqt(a)gmail.com> wrote:
Do we need to split out this dep from perl in RPM spec? Someone says
it's needed and someone doesn't support this idea.
I think this is a non-issue:
% repoquery -q --whatrequires 'perl(strict)' | wc -l
2742
% repoquery --whatprovides 'perl(strict)'
perl-4:5.16.3-265.fc19.x86_64
-T.C.
10:40 p.m.
Yeah I know.
But when sometimes a staff from Red Hat Perl SIG asked me to do that,
what could I say?
12:30 a.m.
On Wed, Jul 3, 2013 at 8:40 PM, Christopher Meng <cickumqt(a)gmail.com> wrote:
Yeah I know.
But when sometimes a staff from Red Hat Perl SIG asked me to do that,
what could I say?
Tell them they should add it to %{perl_default_filter} then instead of
making packagers hack around it in 2,000+ packages?
That being said, the fix for this is just:
%global __provides_exclude ^perl(strict)$
It's not really worth making a fuss over.
-T.C.
2 a.m.
On Wed, 3 Jul 2013 22:30:25 -0700
"T.C. Hollingsworth" <tchollingsworth(a)gmail.com> wrote:
On Wed, Jul 3, 2013 at 8:40 PM, Christopher Meng
<cickumqt(a)gmail.com>
wrote:
> Yeah I know.
>
> But when sometimes a staff from Red Hat Perl SIG asked me to do
> that, what could I say?
Tell them they should add it to %{perl_default_filter} then instead of
making packagers hack around it in 2,000+ packages?
That being said, the fix for this is just:
%global __provides_exclude ^perl(strict)$
It's not really worth making a fuss over.
Christopher has not posted a bug reference so we can't be sure but I
think he's being asked to add a BuildRequires: perl(strict), not a
provides/requires filter.
Paul.
2:31 a.m.
On Thu, 4 Jul 2013 15:03:34 +0800
Christopher Meng <cickumqt(a)gmail.com> wrote:
Well let's see this here:
https://bugzilla.redhat.com/show_bug.cgi?id=979648
As I suspected, you're being asked to add perl(strict) and
perl(warnings) as build requirements. I think that this is mainly for
consistency and completeness, as the chances of these particular
dependencies being split from the main perl package and not being
required by it are pretty much nil.
If you're on the perl-devel list, you'll see that these and other
"implicit" build dependencies are being added to lots of existing
packages at the moment.
Paul.
3:55 a.m.
On 04/07/13 08:49, Christopher Meng wrote:
Well, then just write them up in the guidelines, I follow the rules.
https://fedoraproject.org/wiki/Packaging:Perl#Perl_Requires_and_Provides
"It is recommended to buildrequire core modules explicitly,
because they can move between sub-packages or disappear
from core perl."
Paul.
5:49 a.m.
On Thu, Jul 04, 2013 at 09:55:25AM +0100, Paul Howarth wrote:
On 04/07/13 08:49, Christopher Meng wrote:
>Well, then just write them up in the guidelines, I follow the rules.
https://fedoraproject.org/wiki/Packaging:Perl#Perl_Requires_and_Provides
"It is recommended to buildrequire core modules explicitly,
because they can move between sub-packages or disappear
from core perl."
'use strict' and 'use warnings' are implemented in the interpreter.
There exists 'strict.pm' and 'warnings.pm' modules, but all they do is
to set internal compiler flags, causing the interpreter to emit the
errors/warnings as it processes the code. They are just thin wrappers
and splitting them off from core perl would make no sense.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:35 a.m.
On 04/07/13 11:49, Richard W.M. Jones wrote:
On Thu, Jul 04, 2013 at 09:55:25AM +0100, Paul Howarth wrote:
> On 04/07/13 08:49, Christopher Meng wrote:
>> Well, then just write them up in the guidelines, I follow the rules.
>
> https://fedoraproject.org/wiki/Packaging:Perl#Perl_Requires_and_Provides
>
> "It is recommended to buildrequire core modules explicitly,
> because they can move between sub-packages or disappear
> from core perl."
'use strict' and 'use warnings' are implemented in the interpreter.
There exists 'strict.pm' and 'warnings.pm' modules, but all they do is
to set internal compiler flags, causing the interpreter to emit the
errors/warnings as it processes the code. They are just thin wrappers
and splitting them off from core perl would make no sense.
I agree, and alluded to that before. I personally haven't included any
non-dual-lived modules as buildreqs in my own perl module packages.
However, from the point of view of consistency and simplicity, it's safe
to build-require anything that a package "use"s, "require"s etc., i.e.
it's harmless to add them, and the omission of core module buildreqs has
caused problems in the past, e.g. when Data::Dumper and Digest::MD5 were
sub-packaged. So I wouldn't be averse to a guideline that said to
include all of them, even if they were implemented in the interpreter,
as that's easier to understand and check than a potentially long list of
pragmas and other exceptions.
Paul.
8:52 a.m.
On 2013-07-04, Paul Howarth <paul(a)city-fan.org> wrote:
I agree, and alluded to that before. I personally haven't
included any
non-dual-lived modules as buildreqs in my own perl module packages.
However, from the point of view of consistency and simplicity, it's safe
to build-require anything that a package "use"s, "require"s etc.,
i.e.
it's harmless to add them, and the omission of core module buildreqs has
caused problems in the past, e.g. when Data::Dumper and Digest::MD5 were
sub-packaged. So I wouldn't be averse to a guideline that said to
include all of them, even if they were implemented in the interpreter,
as that's easier to understand and check than a potentially long list of
pragmas and other exceptions.
I agree with Paul. I also used to omit non-dual-living (CPAN or Fedora)
packages but then I figured out that it's easier and less error-prone to
declare all dependencies than to `maintain' a list of modules that will
`never' dual-live.
I'm not a friend of verbose guidelines especially if upper (global
Fedora) guidelines already define the best practices (specify all
dependencies).
However I can see the Perl guidelines are quite out-dated a they would
desire an update. And if it helps to guide packagers, then we can compose
new Perl guidelines.
-- Petr
3970
days inactive
3971
days old
packaging@lists.fedoraproject.org
11 comments
5 participants
participants (5)
-
Christopher Meng -
Paul Howarth -
Petr Pisar -
Richard W.M. Jones -
T.C. Hollingsworth