Since perl is special, perl packages are exempt from the requirement for -devel packages for .h header files.
This has been the status quo for some time, but never explicitly stated. Take a second and vote on this please.
Thanks,
~spot
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged.
- J<
On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote:
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged.
They're installed for the usual reasons - something requires them, usually at build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs DBI's *.h to build, ditto probably all other perl-DBD-*.
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skyttä wrote:
On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote:
> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged.
They're installed for the usual reasons - something requires them, usually at build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs DBI's *.h to build, ditto probably all other perl-DBD-*.
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel. It's much cleaner that way. If it involves major surgery then we'd have to let this pass though, but I assume it will affect only a few.
The packages I've seen carrying *.h files are mostly not suited becoming perl- prefixed anyway (in a monolithic package) as they are carrying more than modules.
Axel Thimm wrote:
On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skyttä wrote:
On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote:
>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged.
They're installed for the usual reasons - something requires them, usually at build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs DBI's *.h to build, ditto probably all other perl-DBD-*.
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel. It's much cleaner that way. If it involves major surgery then we'd have to let this pass though, but I assume it will affect only a few.
The packages I've seen carrying *.h files are mostly not suited becoming perl- prefixed anyway (in a monolithic package) as they are carrying more than modules.
Perl packages that include .h files (excluding the core perl)
Core: 2 perl packages perl-DBI perl-PDL
Extras: 16 perl packages perl-Cairo perl-Event perl-Glib perl-Gnome2-Canvas perl-Gnome2-GConf perl-Gnome2-Print perl-Gnome2-VFS perl-Gtk2 perl-Gtk2-GladeXML perl-Gtk2-Notify perl-Gtk2-Sexy perl-Gtk2-Spell perl-Gtk2-TrayIcon perl-Imager perl-Tk perl-Wx
jpo
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> If it's a small number I'd go with Ville and have them properly AT> split out their *-devel. It's much cleaner that way.
That way leads in many of not most cases to a -devel file containing a single .h file, which I see as being far less clean.
- J<
On Tue, 2007-02-06 at 09:39 -0600, Jason L Tibbitts III wrote:
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> If it's a small number I'd go with Ville and have them properly AT> split out their *-devel. It's much cleaner that way.
That way leads in many of not most cases to a -devel file containing a single .h file, which I see as being far less clean.
That argument did not stop single-file -devel packages for .pc files...
On Tue, 2007-02-06 at 10:25 -0600, Rex Dieter wrote:
Matthias Clasen wrote:
That argument did not stop single-file -devel packages for .pc files..
I agree single-file -devel packages *could* be silly, examples?
iso-codes-devel is one, and I'm sure we have or will soon see a request to put the gnome-icon-theme .pc file in its own -devel, too.
Matthias Clasen wrote:
On Tue, 2007-02-06 at 10:25 -0600, Rex Dieter wrote:
Matthias Clasen wrote:
That argument did not stop single-file -devel packages for .pc files..
I agree single-file -devel packages *could* be silly, examples?
iso-codes-devel is one, and I'm sure we have or will soon see a request to put the gnome-icon-theme .pc file in its own -devel, too.
The relevant section of the guidelines for this is:
- *SHOULD*: The placement of pkgconfig(.pc) files depends on their use case, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
-- Rex
On Tue, 2007-02-06 at 13:13 +0100, Axel Thimm wrote:
On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skyttä wrote:
On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote:
>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged.
They're installed for the usual reasons - something requires them, usually at build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs DBI's *.h to build, ditto probably all other perl-DBD-*.
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel. It's much cleaner that way. If it involves major surgery then we'd have to let this pass though, but I assume it will affect only a few.
The packages I've seen carrying *.h files are mostly not suited becoming perl- prefixed anyway (in a monolithic package) as they are carrying more than modules.
Well, here's a big one:
perl.
Perl has a healthy number of .h files:
/usr/lib/perl5/5.8.8/Encode/encode.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/EXTERN.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/INTERN.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/XSUB.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/av.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cc_runtime.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cop.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/dosish.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/embed.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/embedvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/fakesdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/fakethr.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/form.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/gv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/handy.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/hv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/intrpvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/iperlsys.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/keywords.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/malloc_ctl.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/mg.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/nostdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/op.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/opcode.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/opnames.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pad.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/patchlevel.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perl.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlapi.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perliol.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlsdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlsfio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlvars.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perly.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pp_proto.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/reentr.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regcomp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regexp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regnodes.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/scope.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/sv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/thrdvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/thread.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/uconfig.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/unixish.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/utf8.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/utfebcdic.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/util.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/warnings.h
My concern is that if we make a perl-devel here, some things that had perl as an unstated BuildRequires will suddenly stop building until they add perl-devel.
Not fatal, but rather intrusive. Thoughts?
~spot
On Tuesday 06 February 2007 13:51, Tom 'spot' Callaway wrote:
Not fatal, but rather intrusive. Thoughts?
Now (development cycle, still fairly early on) is the time to make such changes, if they were to be made. Doing so after Test2 is probably not desireable.
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> My concern is that if we make a perl-devel here, some things that TC> had perl as an unstated BuildRequires will suddenly stop building TC> until they add perl-devel.
If so, this needs to happen rather soon. Can we get buy-in from Robin and perhaps a couple of mass-packagers like Steve Pritchard?
- J<
Jason L Tibbitts III wrote:
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> My concern is that if we make a perl-devel here, some things that TC> had perl as an unstated BuildRequires will suddenly stop building TC> until they add perl-devel.
If so, this needs to happen rather soon. Can we get buy-in from Robin and perhaps a couple of mass-packagers like Steve Pritchard?
Imo, lobbying for buy-in is premature. There isn't even consensus (here anyway) that this (perl -devel pkgs) is even a good idea worth pursuing (and if you ask me, it isn't).
-- Rex
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> Imo, lobbying for buy-in is premature.
We should at least ask the people doing the bulk of the Perl work if they think this is reasonable, shouldn't we?
- J<
Jason L Tibbitts III wrote:
"RD" == Rex Dieter rdieter@math.unl.edu writes: RD> Imo, lobbying for buy-in is premature.
We should at least ask the people doing the bulk of the Perl work if they think this is reasonable, shouldn't we?
Sure, go ahead, couldn't hurt.
-- Rex
On Tue, 2007-02-06 at 14:02 -0600, Rex Dieter wrote:
Jason L Tibbitts III wrote:
> "RD" == Rex Dieter rdieter@math.unl.edu writes: > RD> Imo, lobbying for buy-in is premature. > > We should at least ask the people doing the bulk of the Perl work if > they think this is reasonable, shouldn't we? >
Sure, go ahead, couldn't hurt.
Indeed, but Robin is letting me rewrite the perl spec file at the moment. :)
~spot
There's nothing like coming into a discussion *really* late... (Sorry, $dayjob has been hell recently.)
On Tue, Feb 06, 2007 at 01:18:18PM -0600, Jason L Tibbitts III wrote:
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> My concern is that if we make a perl-devel here, some things that TC> had perl as an unstated BuildRequires will suddenly stop building TC> until they add perl-devel.
If so, this needs to happen rather soon. Can we get buy-in from Robin and perhaps a couple of mass-packagers like Steve Pritchard?
My only concern is that some of our BuildRequires will need to be on perl-foo-devel instead of perl(foo), and I may or may not be able to figure that out automatically in cpanspec.
If I were going to look for things to be concerned with in the perl package, I'd probably worry about noarch packages being in /usr/lib/perl5 instead of /usr/share/perl5. :-)
Steve
On Tue, Feb 06, 2007 at 12:51:51PM -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-02-06 at 13:13 +0100, Axel Thimm wrote:
On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skyttä wrote:
On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote:
>>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files.
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel. It's much cleaner that way. If it involves major surgery then we'd have to let this pass though, but I assume it will affect only a few.
The packages I've seen carrying *.h files are mostly not suited becoming perl- prefixed anyway (in a monolithic package) as they are carrying more than modules.
Well, here's a big one:
perl.
That hardly counts as a perl module package otherwise it would ahd been named perl-perl ;)
My concern is that if we make a perl-devel here, some things that had perl as an unstated BuildRequires will suddenly stop building until they add perl-devel.
Not fatal, but rather intrusive. Thoughts?
I would separate discussion of the perl package and the rest. But even if perl itself were to be split in perl and perl-devel, Matt's mass rebuilds would let the packages surface that need a change from BR: perl to BR: perl-devel.
On Tue, 2007-02-06 at 20:31 +0100, Axel Thimm wrote:
Well, here's a big one:
perl.
That hardly counts as a perl module package otherwise it would ahd been named perl-perl ;)
Well, it is a perl module package, it has several perl modules inside of it. The main module in this case is called "CORE", but there is also a .h file in the Encode module (also inside perl).
My concern is that if we make a perl-devel here, some things that had perl as an unstated BuildRequires will suddenly stop building until they add perl-devel.
Not fatal, but rather intrusive. Thoughts?
I would separate discussion of the perl package and the rest. But even if perl itself were to be split in perl and perl-devel, Matt's mass rebuilds would let the packages surface that need a change from BR: perl to BR: perl-devel.
Well, I'm trying to review the core perl package, and part of that has been a near total spec rewrite. I need to know whether I should add a perl-devel or not.
~spot
On Tuesday 06 February 2007 21:35, Tom 'spot' Callaway wrote:
Well, I'm trying to review the core perl package, and part of that has been a near total spec rewrite. I need to know whether I should add a perl-devel or not.
I still haven't formed an opinion, but here's some numbers from i386 FC6:
$ du -hc `rpm -ql perl` | tail -n 1 237M total
$ du -hc `rpm -ql perl | grep '.h$'` | tail -n 1 1.6M total
Not that significant. Also, I haven't checked but would guess that *.h don't inflict any extra dependencies. There's also a bunch of *.ph files which I gather are _mostly_ for development purposes but some modules do pull some of them in at runtime (eg. Net::Domain, Sys::Hostname) so I suppose it's safer to leave at least *.ph alone unless someone knows better.
On Tue, Feb 06, 2007 at 01:35:51PM -0600, Tom 'spot' Callaway wrote:
Well, I'm trying to review the core perl package, and part of that has been a near total spec rewrite. I need to know whether I should add a perl-devel or not.
If there is a mass rebuild (e.g. by Matt's buildsystem) before test2 it could be used to check whether that split really harms anything. But I think perhaps that's us being to pedantic in this case, and we could revisit it after F7.
But it wouldn't hurt to add a forward compatible
Provides: perl-devel = %{epoch}:%{version}-%{release}
That way any current package that should depend on perl-devel instead of or in addition to perl would have a transition time to fix the BRs.
On Tue, 2007-02-06 at 21:54 +0100, Axel Thimm wrote:
On Tue, Feb 06, 2007 at 01:35:51PM -0600, Tom 'spot' Callaway wrote:
Well, I'm trying to review the core perl package, and part of that has been a near total spec rewrite. I need to know whether I should add a perl-devel or not.
If there is a mass rebuild (e.g. by Matt's buildsystem) before test2 it could be used to check whether that split really harms anything. But I think perhaps that's us being to pedantic in this case, and we could revisit it after F7.
OK, being pedantic:
- I can't make perl pass review unless I make a perl-devel OR - Perl needs an exception in the guidelines so it can pass review.
Which one would people prefer for FC-7? At this point, I'm rather indifferent. :)
~spot
On 2/6/07, Tom 'spot' Callaway tcallawa@redhat.com wrote:
OK, being pedantic:
- I can't make perl pass review unless I make a perl-devel
OR
- Perl needs an exception in the guidelines so it can pass review.
Which one would people prefer for FC-7? At this point, I'm rather indifferent. :)
I'd suggest just codifying existing practice... It has worked quite well so far, and there doesn't seem to be a pressing _technical_ reason to change it. (a la a .pc files potential to generate additional deps in the package.)
Steve's point of "we can't just br: perl(Foo) anymore" is well taken, and would seem to be a compelling reason to leave things as is. We would no longer be able to just say "this requires perl(foo) to build" in all cases.
-Chris
On Tuesday 06 February 2007 14:13, Axel Thimm wrote:
On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skyttä wrote:
Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead.
Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel.
Just for the record, I don't have a real opinion yet, so you won't know where you'll end up if you decide to go with me at this point :). All I suggested above was discussion about it (which we now have, good).
Tom 'spot' Callaway wrote:
Since perl is special, perl packages are exempt from the requirement for -devel packages for .h header files.
This has been the status quo for some time, but never explicitly stated. Take a second and vote on this please
I'm ok with it, +1
-- Rex
packaging@lists.fedoraproject.org