From rkearey at redhat.com Mon Apr 18 05:36:16 2005 From: rkearey at redhat.com (Rob Kearey) Date: Mon, 18 Apr 2005 15:36:16 +1000 Subject: Well here we are Message-ID: <42634750.9060000@redhat.com> OK, I'll start with a big, ugly one. CPAN+ can build debian packages with CPANPLUS::Dist. Would it be worthwhile creating an RPM target? Damn you, RT. -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey From ville.skytta at iki.fi Mon Apr 18 06:31:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 18 Apr 2005 09:31:58 +0300 Subject: Well here we are In-Reply-To: <42634750.9060000@redhat.com> References: <42634750.9060000@redhat.com> Message-ID: <1113805918.2607.55.camel@bobcat.mine.nu> On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote: > CPAN+ can build debian packages with CPANPLUS::Dist. Would it be > worthwhile creating an RPM target? Would it offer something that cpan2rpm or RPM-Specfile already don't? From wtogami at redhat.com Mon Apr 18 06:41:42 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Apr 2005 20:41:42 -1000 Subject: Well here we are In-Reply-To: <1113805918.2607.55.camel@bobcat.mine.nu> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> Message-ID: <426356A6.6010508@redhat.com> Ville Skytt? wrote: > On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote: > > >>CPAN+ can build debian packages with CPANPLUS::Dist. Would it be >>worthwhile creating an RPM target? > > > Would it offer something that cpan2rpm or RPM-Specfile already don't? > https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list Chip has expressed that he wants to fix cpanflute2 (shipped in Core) to do exactly what we want. Let's get him on this list. Hey Chip this is the Fedora Project perl team's devel list. I aim to keep list traffic here low noise through strict moderation and zero tolerance for bullshit. While cpanflute2 writing specs closer to the Fedora Project perl spec template would help us, it will never be a fully automated process. Each package needs to be analyzed to disable part or whole of "make test" because it is inappropriate to run network tests in the build system. Other packages need to be told the location of other non-perl software and stuff. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Apr 18 07:08:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Apr 2005 21:08:32 -1000 Subject: Needed: Mission Statement Message-ID: <42635CF0.9050208@redhat.com> We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set. Some ideas for the mission statement: * Agreement and documentation of perl packaging standards * Cleanup and maintenance of Core and Extras perl packages * Discussion of perl package development issues * Progressive packaging of CPAN toward Extras Anything we're missing? This week we need to figure out ways of better keeping the team informed about new bugs, triage and setting priorities, and tracking open issues. I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs at redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher. I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume. Warren Togami wtogami at redhat.com From dgregor at redhat.com Mon Apr 18 14:52:28 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Mon, 18 Apr 2005 10:52:28 -0400 Subject: Needed: Mission Statement In-Reply-To: <42635CF0.9050208@redhat.com> References: <42635CF0.9050208@redhat.com> Message-ID: <1113835948.20736.37.camel@dhcp83-103.boston.redhat.com> On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote: > We're about ready to announce this list on fedora-devel-list and > fedora-extras-list, but before we do we should write a mission > statement. I personally intend on keeping list traffic low noise and > high relevancy by enforcing strict moderation. Anything straying from > the mission statement will have a single warning, then second infraction > moderate bit set. > > Some ideas for the mission statement: > > * Agreement and documentation of perl packaging standards > * Cleanup and maintenance of Core and Extras perl packages > * Discussion of perl package development issues > * Progressive packaging of CPAN toward Extras > > Anything we're missing? Those all sound good. Also, we may want to define a policy for which Perl packages are allowed into Extras. (for example, do they have to be in CPAN first?) > > > This week we need to figure out ways of better keeping the team informed > about new bugs, triage and setting priorities, and tracking open issues. > > I am thinking perhaps we should auto-CC all FC and FE perl* packages to > a fedora-perl-bugs at redhat.com list, and anybody that wants to follow all > perl reports subscribe to that list. This is easier to maintain than > adding several people auto-CC to hundreds of packages in Bugzilla. Then > we can set filters on that list so only the most important types of bug > mail are sent there in order to keep relevancy higher. > > I realize this isn't ideal, so very interested to hear your ideas of how > we can better balance keeping informed with traffic volume. I just did a query and there 67 open bugs in perl* components of FC and FE. This doesn't seem like all that many to me. I like the idea of an auto-CC to fedora-perl-bugs at redhat.com. Additionally, I think it would be worthwhile to email this list when a new Perl component is added (or removed) from bugzilla. Cheers -- Dennis From dgregor at redhat.com Mon Apr 18 16:03:56 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Mon, 18 Apr 2005 12:03:56 -0400 Subject: Well here we are In-Reply-To: <426356A6.6010508@redhat.com> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> Message-ID: <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> On Sun, 2005-04-17 at 20:41 -1000, Warren Togami wrote: > Ville Skytt? wrote: > > On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote: > > > > > >>CPAN+ can build debian packages with CPANPLUS::Dist. Would it be > >>worthwhile creating an RPM target? > > > > > > Would it offer something that cpan2rpm or RPM-Specfile already don't? > > > > https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list > Chip has expressed that he wants to fix cpanflute2 (shipped in Core) to > do exactly what we want. Let's get him on this list. Hey Chip this is > the Fedora Project perl team's devel list. I aim to keep list traffic > here low noise through strict moderation and zero tolerance for bullshit. > > While cpanflute2 writing specs closer to the Fedora Project perl spec > template would help us, it will never be a fully automated process. > Each package needs to be analyzed to disable part or whole of "make > test" because it is inappropriate to run network tests in the build > system. Other packages need to be told the location of other non-perl > software and stuff. Even if we can't fully automate the process, the more we can automate, the better. My question is: which of the available tools[1] should we focus on? If Chip is looking to work on cpanflute2, that would be great. A CPANPLUS::Dist::RPM module would be useful for installing Perl modules as RPMs created on-the-fly, but that's not quite what we need in Fedora Extras. -- Dennis 1. http://gsd.di.uminho.pt/jpo/perl/specfiles/#TOOLS From ville.skytta at iki.fi Mon Apr 18 17:25:15 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 18 Apr 2005 20:25:15 +0300 Subject: Well here we are In-Reply-To: <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> Message-ID: <1113845115.6812.40.camel@bobcat.mine.nu> On Mon, 2005-04-18 at 12:03 -0400, Dennis Gregorovic wrote: > Even if we can't fully automate the process, the more we can automate, > the better. My question is: which of the available tools[1] should we > focus on? If Chip is looking to work on cpanflute2, that would be > great. Could you elaborate on what exactly what process are you talking about? Automagically packaging as many CPAN modules as possible? There's already http://rpmpan.sourceforge.net/ which IIRC uses cpanflute2, but I have no real experience with it (RPMPan). They probably have quite a bit of experience in doing this. cpanflute2 could be tweaked more towards suitability for Fedora/RHEL purposes, but I'm afraid doing so could make it less useful for other distros. That's Chip's call, of course. I don't personally believe in blindly autopackaging stuff in the first place (not only for Perl modules), but maybe you're not talking about this. > A CPANPLUS::Dist::RPM module would be useful for installing Perl modules > as RPMs created on-the-fly, but that's not quite what we need in Fedora > Extras. yum install fedora-rpmdevtools emacs perl-Foo.spec # or xemacs # (X)Emacs containing a pre-filled Perl spec template comes up, just # fill in the blanks and save it. spectool -g -R perl-Foo.spec rpmbuild -ba perl-Foo.spec The above is enough for me for now... if for some weird reason someone uses vi :), maybe similar stuff can be hacked up for it too. Somewhat OT: stuff I haven't seen mentioned elsewhere that could be useful for automatically finding (Build)Dependencies, maybe someone has used or evaluated some of these? rpmbuild obviously already has internal magic for the install time deps, but tools like cpanflute2 could use something like these for pre-filling build deps. http://search.cpan.org/dist/Module-Depends/ http://search.cpan.org/dist/Module-Dependency/ http://search.cpan.org/dist/Module-ExtractUse/ http://search.cpan.org/dist/Module-Info/ http://search.cpan.org/dist/Module-MakefilePL-Parse/ http://search.cpan.org/dist/Module-ScanDeps/ From rkearey at redhat.com Mon Apr 18 23:23:19 2005 From: rkearey at redhat.com (Rob Kearey) Date: Tue, 19 Apr 2005 09:23:19 +1000 Subject: Well here we are In-Reply-To: <1113845115.6812.40.camel@bobcat.mine.nu> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> <1113845115.6812.40.camel@bobcat.mine.nu> Message-ID: <42644167.3040406@redhat.com> Ville Skytt? wrote: > I don't personally believe in blindly autopackaging stuff in the first > place (not only for Perl modules), but maybe you're not talking about > this. CPAN being what it is, I can't see much alternative. -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey From thm at duke.edu Tue Apr 19 15:34:03 2005 From: thm at duke.edu (Hunter Matthews) Date: Tue, 19 Apr 2005 11:34:03 -0400 Subject: Well here we are In-Reply-To: <42644167.3040406@redhat.com> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> <1113845115.6812.40.camel@bobcat.mine.nu> <42644167.3040406@redhat.com> Message-ID: <1113924843.2825.15.camel@jade.biology.duke.edu> On Mon, 2005-04-18 at 19:23, Rob Kearey wrote: > Ville Skytt? wrote: > > > I don't personally believe in blindly autopackaging stuff in the first > > place (not only for Perl modules), but maybe you're not talking about > > this. > > CPAN being what it is, I can't see much alternative. I'm sorry, I didn't understand the context here - You don't see any alternative BUT to autopackage CPAN, or you don't see any alternative except NOT autopackaging CPAN? -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From rkearey at redhat.com Tue Apr 19 23:38:24 2005 From: rkearey at redhat.com (Rob Kearey) Date: Wed, 20 Apr 2005 09:38:24 +1000 Subject: Well here we are In-Reply-To: <1113924843.2825.15.camel@jade.biology.duke.edu> References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1113840236.20736.51.camel@dhcp83-103.boston.redhat.com> <1113845115.6812.40.camel@bobcat.mine.nu> <42644167.3040406@redhat.com> <1113924843.2825.15.camel@jade.biology.duke.edu> Message-ID: <42659670.4090105@redhat.com> Hunter Matthews wrote: >>CPAN being what it is, I can't see much alternative. > I'm sorry, I didn't understand the context here - > You don't see any alternative BUT to autopackage CPAN, or you don't see > any alternative except NOT autopackaging CPAN? The former. I'm happy to be wrong though. -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey From wtogami at redhat.com Thu Apr 21 00:01:00 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 14:01:00 -1000 Subject: Needed: Mission Statement In-Reply-To: <1113835948.20736.37.camel@dhcp83-103.boston.redhat.com> References: <42635CF0.9050208@redhat.com> <1113835948.20736.37.camel@dhcp83-103.boston.redhat.com> Message-ID: <4266ED3C.9090700@redhat.com> Dennis Gregorovic wrote: > On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote: > >>We're about ready to announce this list on fedora-devel-list and >>fedora-extras-list, but before we do we should write a mission >>statement. I personally intend on keeping list traffic low noise and >>high relevancy by enforcing strict moderation. Anything straying from >>the mission statement will have a single warning, then second infraction >>moderate bit set. >> >>Some ideas for the mission statement: >> >>* Agreement and documentation of perl packaging standards >>* Cleanup and maintenance of Core and Extras perl packages >>* Discussion of perl package development issues >>* Progressive packaging of CPAN toward Extras >> >>Anything we're missing? > > > Those all sound good. Also, we may want to define a policy for which > Perl packages are allowed into Extras. (for example, do they have to be > in CPAN first?) Specifics like that don't belong in the mission statement, but a more detailed document elsewhere that expands on the mission statement. Another specific would be fixing RPM's perl dep finder to be smarter by default. Like never pull in Win32, never parse %doc or example(s) dirs, etc. That would eliminate the majority of cases where ugly manual Requires filtering is needed, but not all. >> >>This week we need to figure out ways of better keeping the team informed >>about new bugs, triage and setting priorities, and tracking open issues. >> >>I am thinking perhaps we should auto-CC all FC and FE perl* packages to >>a fedora-perl-bugs at redhat.com list, and anybody that wants to follow all >>perl reports subscribe to that list. This is easier to maintain than >>adding several people auto-CC to hundreds of packages in Bugzilla. Then >>we can set filters on that list so only the most important types of bug >>mail are sent there in order to keep relevancy higher. >> >>I realize this isn't ideal, so very interested to hear your ideas of how >>we can better balance keeping informed with traffic volume. > > > I just did a query and there 67 open bugs in perl* components of FC and > FE. This doesn't seem like all that many to me. I like the idea of an > auto-CC to fedora-perl-bugs at redhat.com. Additionally, I think it would > be worthwhile to email this list when a new Perl component is added (or > removed) from bugzilla. > Good idea. I'll make the request for that mailing list. Time to launch probably Thursday or Friday. Warren Togami wtogami at redhat.com From dgregor at redhat.com Thu Apr 21 00:28:24 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Wed, 20 Apr 2005 20:28:24 -0400 Subject: Needed: Mission Statement In-Reply-To: <4266ED3C.9090700@redhat.com> References: <42635CF0.9050208@redhat.com> <1113835948.20736.37.camel@dhcp83-103.boston.redhat.com> <4266ED3C.9090700@redhat.com> Message-ID: <1114043304.4469.27.camel@dhcp83-103.boston.redhat.com> On Wed, 2005-04-20 at 14:01 -1000, Warren Togami wrote: > Dennis Gregorovic wrote: > > On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote: > > > >>We're about ready to announce this list on fedora-devel-list and > >>fedora-extras-list, but before we do we should write a mission > >>statement. I personally intend on keeping list traffic low noise and > >>high relevancy by enforcing strict moderation. Anything straying from > >>the mission statement will have a single warning, then second infraction > >>moderate bit set. > >> > >>Some ideas for the mission statement: > >> > >>* Agreement and documentation of perl packaging standards > >>* Cleanup and maintenance of Core and Extras perl packages > >>* Discussion of perl package development issues > >>* Progressive packaging of CPAN toward Extras > >> > >>Anything we're missing? > > > > > > Those all sound good. Also, we may want to define a policy for which > > Perl packages are allowed into Extras. (for example, do they have to be > > in CPAN first?) > > Specifics like that don't belong in the mission statement, but a more > detailed document elsewhere that expands on the mission statement. > > Another specific would be fixing RPM's perl dep finder to be smarter by > default. Like never pull in Win32, never parse %doc or example(s) dirs, > etc. That would eliminate the majority of cases where ugly manual > Requires filtering is needed, but not all. Agreed. I wasn't thinking clearly when making those comments. [snip] From wtogami at redhat.com Thu Apr 21 00:58:59 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 14:58:59 -1000 Subject: perl 5.8.7 and FC4? Message-ID: <4266FAD3.80106@redhat.com> How soon is perl-5.8.7 coming? Freeze for test3 is coming April 27th, so if we want perl-5.8.7 in we need upgrade it, test and fix all dependencies and prove that it doesn't cause widespread problems by the 26th. It is highly unlikely we will be able to upgrade to perl-5.8.7 after test3 unless the change is really only minor. How large of a difference is it between 5.8.6 and 5.8.7? It maintains binary compat right? Any other potential issues? Warren Togami wtogami at redhat.com From jpo at di.uminho.pt Thu Apr 21 01:34:06 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 21 Apr 2005 02:34:06 +0100 Subject: perl 5.8.7 and FC4? In-Reply-To: <4266FAD3.80106@redhat.com> References: <4266FAD3.80106@redhat.com> Message-ID: <4267030E.6020706@di.uminho.pt> Warren, > How soon is perl-5.8.7 coming? Freeze for test3 is coming April 27th, > so if we want perl-5.8.7 in we need upgrade it, test and fix all > dependencies and prove that it doesn't cause widespread problems by the > 26th. I don't think perl 5.8.7 will be released in time. In February Nicholas Clark (the current perl 5.8 pumpkin manager) announced the release was imminent (http://www.mail-archive.com/perl5-porters at perl.org/msg84936.html). Last month (2005-03-31) I send him an email requesting furthert information and he replied that he expected to release it in the next three weeks and until now I haven't seen no new developments (emails, snapshots, RCs) in the perl5-porters mailing list. > It is highly unlikely we will be able to upgrade to perl-5.8.7 after > test3 unless the change is really only minor. How large of a difference > is it between 5.8.6 and 5.8.7? It maintains binary compat right? Any > other potential issues? Perl 5.8.7 shouldn't have new features, only bug corrections and core modules updates (eg: Time::HiRes, CGI, ...). It is expected to maintain binary compat (all major perl versions do that - 5.6 and 5.8; perl 5.8.1 being the exception). Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Thu Apr 21 01:48:22 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 21 Apr 2005 02:48:22 +0100 Subject: FC4: modperl, CGI, and perl (problem) Message-ID: <42670666.9000707@di.uminho.pt> Warren, We have another major problem with mod_perl 2.0.0 RC5 as it also requires CGI.pm version 3.08 which has just hit CPAN today (a couple of hours ago). CGI.pm is one of the perl modules affected by the module rename (Apache:: -> Apache2::) done in mod_perl RC5. Problem: How to package CGI 3.08? CGI.pm is a dual life perl module: shipped with perl and also shipped as an independent module . Possible solutions: 1) patching perl-5.8.6 2) remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9 3) wait for perl-5.8.7 and hope that it includes CGI 3.08. Option 3 is rather optimistic. Even if perl-5.8.7 is released next week, it will probably be to late to include it in FC4. Option 1 or option 2? Right now I would go for option 2. It will be easier to release updates if something is still broken. Comments? [Warren: is there any change of updating perl after test3 if it doesn't break anything?] Regards, jpo PS - Joe Orton knows about this problem. One of the mails in the mod_perl mailing list was his. References: [1] mod_perl 2.0 renaming http://perl.apache.org/docs/2.0/rename.html [2] Lincoln D. Stein > CGI.pm http://search.cpan.org/dist/CGI.pm/ -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jefffearn at gmail.com Thu Apr 21 02:04:42 2005 From: jefffearn at gmail.com (Jeff Fearn) Date: Thu, 21 Apr 2005 12:04:42 +1000 Subject: Creating RPMs for perl Distributions Message-ID: <2411051405042019042113ad@mail.gmail.com> Hi all, I'm doing a little hacking for RobK trying to get cpan2rpm to recursively build rpms for perl modules. I have it working for perl Modules but am stuck trying to work out how to handle Distributions, such as libapreq. I can get them to d/l and supply dependencies etc, I just haven't figured out how to convert the tar to an rpm. Any pointers are most welcome :) Jeff From wtogami at redhat.com Thu Apr 21 02:04:20 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 16:04:20 -1000 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <42670666.9000707@di.uminho.pt> References: <42670666.9000707@di.uminho.pt> Message-ID: <42670A24.9060209@redhat.com> Jos? Pedro Oliveira wrote: > Warren, > > We have another major problem with mod_perl 2.0.0 RC5 as it also > requires CGI.pm version 3.08 which has just hit CPAN today (a couple > of hours ago). CGI.pm is one of the perl modules affected by > the module rename (Apache:: -> Apache2::) done in mod_perl RC5. > > > Problem: > How to package CGI 3.08? > CGI.pm is a dual life perl module: shipped with perl > and also shipped as an independent module . > > > Possible solutions: > 1) patching perl-5.8.6 > 2) remove CGI from the core perl package and and go back > to perl-CGI as it was done in Red Hat 7.3, 8, and 9 > 3) wait for perl-5.8.7 and hope that it includes CGI 3.08. > If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now would be a hassle because it is a temporary situation. To make matters worse the existing perl packages contain "Obsoletes: perl-CGI" which may cause problems for us. For these reasons it may be better to patch perl-5.8.6. Short-term ugliness for simpler long term maintenance? Maybe my opinion here is totally wrong, so I would wait for Ville to choose between #1 or #2. How large would a patch for solution #1 be? Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Apr 21 02:10:55 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 16:10:55 -1000 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <42670666.9000707@di.uminho.pt> References: <42670666.9000707@di.uminho.pt> Message-ID: <42670BAF.1080701@redhat.com> Jos? Pedro Oliveira wrote: > > [Warren: is there any change of updating perl after test3 if > it doesn't break anything?] > Highly unlikely. Even if we can prove with a test-tree that it breaks nothing and fixes several bugs, the choice is up to Sopwith. We can't make those kinds of guarantees today because perl-5.8.7 isn't released. Warren Togami wtogami at redhat.com From jpo at di.uminho.pt Thu Apr 21 02:51:46 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 21 Apr 2005 03:51:46 +0100 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <42670A24.9060209@redhat.com> References: <42670666.9000707@di.uminho.pt> <42670A24.9060209@redhat.com> Message-ID: <42671542.2070805@di.uminho.pt> Warren Togami wrote: > Jos? Pedro Oliveira wrote: > >> Warren, >> >> We have another major problem with mod_perl 2.0.0 RC5 as it also >> requires CGI.pm version 3.08 which has just hit CPAN today (a couple >> of hours ago). CGI.pm is one of the perl modules affected by >> the module rename (Apache:: -> Apache2::) done in mod_perl RC5. >> >> >> Problem: >> How to package CGI 3.08? >> CGI.pm is a dual life perl module: shipped with perl >> and also shipped as an independent module . >> >> >> Possible solutions: >> 1) patching perl-5.8.6 >> 2) remove CGI from the core perl package and and go back >> to perl-CGI as it was done in Red Hat 7.3, 8, and 9 >> 3) wait for perl-5.8.7 and hope that it includes CGI 3.08. >> > > If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now > would be a hassle because it is a temporary situation. To make matters > worse the existing perl packages contain "Obsoletes: perl-CGI" which may > cause problems for us. For these reasons it may be better to patch > perl-5.8.6. Short-term ugliness for simpler long term maintenance? > > Maybe my opinion here is totally wrong, so I would wait for Ville to > choose between #1 or #2. > > How large would a patch for solution #1 be? Perl-5.8.6 ships with CGI.pm 3.05. Mod_perl 2.0.0 RC5 requires CGI.pm 3.08. Patches in unified format (3.05 -> 3.08) 1) Full patch is around 141 KB. 2) If we exclude the docs (README, Changes, and cgi_docs.html) we can reduce the patch to 89 KB. Note: the CGI documentation files aren't ship with perl. Source files: 4e1e2288369089e56e8a115aade93ea4 CGI.pm-3.05.tar.gz 6f13f09e498cacd37ceb271443269b8d CGI.pm-3.08.tar.gz jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Thu Apr 21 07:05:53 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Apr 2005 10:05:53 +0300 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <42671542.2070805@di.uminho.pt> References: <42670666.9000707@di.uminho.pt> <42670A24.9060209@redhat.com> <42671542.2070805@di.uminho.pt> Message-ID: <1114067153.6812.313.camel@bobcat.mine.nu> On Thu, 2005-04-21 at 03:51 +0100, Jos? Pedro Oliveira wrote: > Warren Togami wrote: > > Jos? Pedro Oliveira wrote: > > > >> Possible solutions: > >> 1) patching perl-5.8.6 > >> 2) remove CGI from the core perl package and and go back > >> to perl-CGI as it was done in Red Hat 7.3, 8, and 9 > >> 3) wait for perl-5.8.7 and hope that it includes CGI 3.08. > > > > If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now > > would be a hassle because it is a temporary situation. To make matters > > worse the existing perl packages contain "Obsoletes: perl-CGI" which may > > cause problems for us. For these reasons it may be better to patch > > perl-5.8.6. Short-term ugliness for simpler long term maintenance? > > > > Maybe my opinion here is totally wrong, so I would wait for Ville to > > choose between #1 or #2. I think it's better to wait first if 5.8.7 makes it in time for FC-4, and if it contains CGI 3.08. If not, both #1 and #2 have their advantages and disadvantages, and #1 can be split into "patch only as much as necessary to make it work with the new mod_perl", or do a full update to 3.08 in it. The separation could cause a chicken-egg bootstrap problem. To be on the safe side, the perl package should have "Requires: perl-CGI >= 3.05". But the perl package is also a build dependency for the now separated perl-CGI... of course, it is possible to cheat around this by using the old perl package to build the new CGI first, then build a new perl that requires the separated CGI. But as said that would be cheating. Another approach in the separation would be to not have the Requires: perl-CGI in perl. That would break the dependecies for packages that just assume CGI being present if perl is, instead of containing an explicit (possibly autogenerated) dependency on perl(CGI). Regarding the Obsoletes:, all of those should really be made versioned in the perl specfile. That version needs to be bumped on every upstream Perl release as necessary -> more maintenance, although not _that_ much. Adding versioned Provides: for these would be nice too. > > How large would a patch for solution #1 be? > > Perl-5.8.6 ships with CGI.pm 3.05. > Mod_perl 2.0.0 RC5 requires CGI.pm 3.08. > > Patches in unified format (3.05 -> 3.08) > 1) Full patch is around 141 KB. > 2) If we exclude the docs (README, Changes, and cgi_docs.html) > we can reduce the patch to 89 KB. If the patch upgrade will be to the full 3.08, I don't think implementing it as a patch file adds much value. Just bundle the full updated CGI modules in the SRPM and copy into place during build. The "patch only necessary bits" approach would result in something like: http://search.cpan.org/diff?from=CGI.pm-3.07&to=CGI.pm-3.08 The 3.05->3.07 diff would need to be checked for related bits too. No strong opinions between these three approaches. Perhaps leaning slightly towards the full patch option at the moment. From wtogami at redhat.com Thu Apr 21 21:57:17 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Apr 2005 11:57:17 -1000 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <1114067153.6812.313.camel@bobcat.mine.nu> References: <42670666.9000707@di.uminho.pt> <42670A24.9060209@redhat.com> <42671542.2070805@di.uminho.pt> <1114067153.6812.313.camel@bobcat.mine.nu> Message-ID: <426821BD.2050706@redhat.com> Ville Skytt? wrote: > > I think it's better to wait first if 5.8.7 makes it in time for FC-4, > and if it contains CGI 3.08. If not, both #1 and #2 have their > advantages and disadvantages, and #1 can be split into "patch only as > much as necessary to make it work with the new mod_perl", or do a full > update to 3.08 in it. Just talked to Sopwith and notting. perl-5.8.7 after test3 is not going to be possible. Can you magically make perl-5.8.7 happen upstream by Saturday, and have everything tested by Monday for inclusion? Otherwise it is impossible. > > The separation could cause a chicken-egg bootstrap problem. To be on > the safe side, the perl package should have "Requires: perl-CGI >= > 3.05". But the perl package is also a build dependency for the now > separated perl-CGI... of course, it is possible to cheat around this by > using the old perl package to build the new CGI first, then build a new > perl that requires the separated CGI. But as said that would be > cheating. > > Another approach in the separation would be to not have the Requires: > perl-CGI in perl. That would break the dependecies for packages that > just assume CGI being present if perl is, instead of containing an > explicit (possibly autogenerated) dependency on perl(CGI). > > Regarding the Obsoletes:, all of those should really be made versioned > in the perl specfile. That version needs to be bumped on every upstream > Perl release as necessary -> more maintenance, although not _that_ much. > Adding versioned Provides: for these would be nice too. Sopwith prefers the patching solution. While ugly it causes the fewest problems for us. Please open a new bug and submit the patch. This will at least guarantee that mod_perl works in FC4. Warren Togami wtogami at redhat.com From cturner at pattern.net Sat Apr 23 07:52:43 2005 From: cturner at pattern.net (Chip Turner) Date: Sat, 23 Apr 2005 03:52:43 -0400 Subject: CGI vs mod_perl vs perl Message-ID: (sorry for starting a new thread; just joined the list) Ahh, the age old conflict of the modules inside of perl vs the modules external to it. Ahh, the pain. Damned if you do, damned if you don't. ... time for a story ... Once upon a time, the happy new Perl maintainer looked around and saw several parts of perl that (he thought) would need updating regularly. "I know what to do!" he said aloud, and quickly split the perl package up into a main perl package and various subpackages such as perl-CGI. "Now when a new perl-CGI comes along, we just release a new RPM made from the CGI upstream distribution, replacing the one that originally was part of perl!" Woe be unto him, though, that releases an update to a package that comes from a different source rpm. The sky will crack and the earth will boil! Users will be confused, and tools will be flustered. Especially if newer versions of that original package are released, then obsoleting the first update that was from a different source rpm! And so, only after splitting out the packages did the happy new Perl maintainer realize the error of his ways. Unable to make ammends for past sins, he tucked his tail between his legs, turned the nasty split perl package back into a single package, and went to pay his penance (mucking the stalls for the king). ... the end ... So my original idea of solving this problem once was to split out perl-CGI and then release updates to it. Bad idea. Wouldn't have worked. So subsequently what I did with things like perl-Time-HiRes was completely destroy them from the perl package so that they -had- to be external packages. You can see examples of such expurgation in the current perl.spec file: find $RPM_BUILD_ROOT -name '*HiRes*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*Filter*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv Begone! Begone, foul packages. So, this is an option for perl-CGI going forward, if frequent updates are anticipated. If not, though, I would recommend just patching it inside of the perl specfile. I am pretty sure I've done that in the past (even with CGI.pm, iirc) with success. Including the upstream CGI tarball, though, in the RPM as another Source would probably be more trouble than it is worth in terms of getting it to build right and then later updating the spec file to perl 5.8.7 which would no longer need the CGI.pm (in one case you just remove a patch file and a %patch statement; in the other, you excise chunks of the build, etc). HTH, Chip -- Chip Turner cturner at pattern.net From cturner at pattern.net Sat Apr 23 07:42:06 2005 From: cturner at pattern.net (Chip Turner) Date: Sat, 23 Apr 2005 03:42:06 -0400 Subject: Well here we are In-Reply-To: <426356A6.6010508@redhat.com> (Warren Togami's message of "Sun, 17 Apr 2005 20:41:42 -1000") References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> Message-ID: Warren Togami writes: > Ville Skytt? wrote: >> On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote: >> >>> CPAN+ can build debian packages with CPANPLUS::Dist. Would it be >>> worthwhile creating an RPM target? >> Would it offer something that cpan2rpm or RPM-Specfile already don't? >> > > https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list > Chip has expressed that he wants to fix cpanflute2 (shipped in Core) > to do exactly what we want. Let's get him on this list. Hey Chip > this is the Fedora Project perl team's devel list. I aim to keep list > traffic here low noise through strict moderation and zero tolerance > for bullshit. > > While cpanflute2 writing specs closer to the Fedora Project perl spec > template would help us, it will never be a fully automated > process. Each package needs to be analyzed to disable part or whole of > "make test" because it is inappropriate to run network tests in the > build system. Other packages need to be told the location of other > non-perl software and stuff. Hi guys! Sorry for the late response. Been a busy couple weeks (new job, moved across country, all those convenient excuses). I am indeed happy to improve RPM-Specfile in whatever ways we can brainstorm and in whatever ways will help Fedora. Right now, the source is embedded in the middle of my own personal subversion repo, but I can split it out into something more public if people are interested. I've read over the archives (still waiting for moderator approval to join), but as far as RPM-Specfile's general use... well, it's always been intended to work on RHL/RHEL/Fedora. I'm not aware of anyone who really used it on other distros. That's not to say I would blindly make it forever incompatible with other distros, but the priority has always been supporting RHEL/Fedora and so I'm comfortable keeping along that same path. I agree also that just packaging every tarball is a bad idea... there's a lot of bad stuff on CPAN. But, ideally, it should be as simple as saying 'make an rpm of Fritzy-Blip' and it happens, so that we can rapidly package as much interesting stuff as possible. So... what do we need cpanflute2 to do better? Chip -- Chip Turner cturner at pattern.net From jpo at di.uminho.pt Sat Apr 23 21:04:08 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 23 Apr 2005 22:04:08 +0100 (WEST) Subject: CGI vs mod_perl vs perl (and others) In-Reply-To: References: Message-ID: <1480.213.13.86.79.1114290248.squirrel@webmail.lsd.di.uminho.pt> Chip Turner, > ... > So my original idea of solving this problem once was to split out > perl-CGI and then release updates to it. Bad idea. Wouldn't have > worked. So subsequently what I did with things like perl-Time-HiRes > was completely destroy them from the perl package so that they -had- > to be external packages. You can see examples of such expurgation in > the current perl.spec file: > > find $RPM_BUILD_ROOT -name '*HiRes*' | xargs rm -rfv > find $RPM_BUILD_ROOT -name '*Filter*' | xargs rm -rfv > find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv > > Begone! Begone, foul packages. > ... A couple of question and notes about the above lines: 1) *HiRes* => perl-Time-HiRes Do you agree in bringing Time::HiRes back to the perl core package? Perl 5.8 has been having a pretty fast release cycle with the pumpkin manager Nicholas Clark: a new release almost every four months (although I remember reading somewhere - maybe in the perl5-porters mailing lists - that they were planning in increasing the time between new 5.8 releases to 6 months). Pumpkin manager Nicholas Clark 5.8.2 2003-Nov-05 5.8.3 2004-Jan-14 5.8.4 2004-Apr-21 5.8.5 2004-Jul-19 5.8.6 2004-Nov-27 2) *Filter* => perl-Filter and perl-Filter-Simple The removal of Filter files causes similar problems Filter::Util::Call (perl-Filter) -------------------------------- Perl version Core module Filter::Util::Call 5.008 1.06 5.008001 1.0601 5.008002 1.0601 5.008003 1.0601 5.008004 1.0601 5.008005 1.0601 5.008006 1.0601 CPAN module id = Filter::Util::Call DESCRIPTION Interface for creation of Perl Filters CPAN_USERID PMQS (Paul Marquess ) CPAN_VERSION 1.06 CPAN_FILE P/PM/PMQS/Filter-1.30.tar.gz The CPAN module version is older than the one shipped with Perl. The CPAN Filter distribution has more files than the ones shipped with perl. Proposal: Ship the core perl module and drop the external perl-Filter package. Filter::Simple (perl-Filter-Simple) ----------------------------------- Perl version Core module Filter::Simple 5.008 0.78 5.008001 0.78 5.008002 0.78 5.008003 0.78 5.008004 0.78 5.008005 0.78 5.008006 0.78 CPAN Module id = Filter::Simple DESCRIPTION Simplified source filtering CPAN_USERID DCONWAY (Damian Conway ) CPAN_VERSION 0.79 CPAN_FILE D/DC/DCONWAY/Filter-Simple-0.79.tar.gz The CPAN module is newer than the one shipped with core Perl. Try to have it updated upstream (ping perl5-portes). 3) *NDBM* => /dev/null ? Why has this module been erased? As far as I can tell there is no external perl module being packaged with NDBM. Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From wtogami at redhat.com Sun Apr 24 10:55:11 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Apr 2005 00:55:11 -1000 Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <426821BD.2050706@redhat.com> References: <42670666.9000707@di.uminho.pt> <42670A24.9060209@redhat.com> <42671542.2070805@di.uminho.pt> <1114067153.6812.313.camel@bobcat.mine.nu> <426821BD.2050706@redhat.com> Message-ID: <426B7B0F.9010401@redhat.com> Warren Togami wrote: > > > Sopwith prefers the patching solution. While ugly it causes the fewest > problems for us. > > Please open a new bug and submit the patch. This will at least > guarantee that mod_perl works in FC4. Someone going to supply the patch for FC4's perl-5.8.6? We really shouldn't ship test3 with broken mod_perl. Warren From wtogami at redhat.com Sun Apr 24 11:03:33 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Apr 2005 01:03:33 -1000 Subject: Needed: Mission Statement In-Reply-To: <42635CF0.9050208@redhat.com> References: <42635CF0.9050208@redhat.com> Message-ID: <426B7D05.8030209@redhat.com> Warren Togami wrote: > I am thinking perhaps we should auto-CC all FC and FE perl* packages to > a fedora-perl-bugs at redhat.com list, and anybody that wants to follow all > perl reports subscribe to that list. This is easier to maintain than > adding several people auto-CC to hundreds of packages in Bugzilla. Then > we can set filters on that list so only the most important types of bug > mail are sent there in order to keep relevancy higher. > > I realize this isn't ideal, so very interested to hear your ideas of how > we can better balance keeping informed with traffic volume. I'm reconsidering the fedora-perl-bugs list idea for two reasons: 1) There is no way to post FC bugs with embargo and hide that traffic from the list. By default anybody subscribed there would see the security embargoed details and so would the list archive. 2) It is *annoying* to receive both bug mail directly, and a duplicate from a bug distribution list. Bugzilla has no way of knowing that you would receive it twice. Although this would be helped by filtering the list mail before bug mail... OK only #1 is a real problem. That problem only makes this feasible if we have a way of creating hidden bugs without adding auto-CC. Current Bugzilla this is not possible. The alternative to this list is to add the few perl team leaders auto-CC to all perl* FC packages. Those members would be privy to embargo details and expected to keep it private until the embargo lift date. Or maybe this worry isn't too bad, because embargo on perl* really does not happen often? I have no clue... Thoughts? Warren Togami wtogami at redhat.com From jpo at di.uminho.pt Sun Apr 24 15:05:10 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 24 Apr 2005 16:05:10 +0100 (WEST) Subject: FC4: modperl, CGI, and perl (problem) In-Reply-To: <426B7B0F.9010401@redhat.com> References: <42670666.9000707@di.uminho.pt> <42670A24.9060209@redhat.com> <42671542.2070805@di.uminho.pt> <1114067153.6812.313.camel@bobcat.mine.nu><426821BD.2050706@redhat.com> <426B7B0F.9010401@redhat.com> Message-ID: <1178.213.13.86.94.1114355110.squirrel@webmail.lsd.di.uminho.pt> > Warren Togami wrote: >> >> Sopwith prefers the patching solution. While ugly it causes the fewest >> problems for us. >> >> Please open a new bug and submit the patch. This will at least >> guarantee that mod_perl works in FC4. > > Someone going to supply the patch for FC4's perl-5.8.6? We really > shouldn't ship test3 with broken mod_perl. Patches in bugzilla entry #155839. Bug 155839 ? perl: CGI update to version 3.08 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155839 If someone could review them would be great. Perl builds and passes CGI tests without problems. Didn't had time to test mod_perl CGI apps. Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From wtogami at redhat.com Sun Apr 24 22:37:09 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Apr 2005 12:37:09 -1000 Subject: Michael Peters review Message-ID: <426C1F95.4010207@redhat.com> http://mpeters.us/fc_extras/ Michael Peters is requesting cvsextras access. Among his packages are some perl packages. Are these good? (This is not the only criteria I am judging for his membership, I am reviewing his other activites in other mailing lists to judge cluefulness.) Warren Togami wtogami at redhat.com From dgregor at redhat.com Mon Apr 25 17:04:48 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Mon, 25 Apr 2005 13:04:48 -0400 Subject: Well here we are In-Reply-To: References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> Message-ID: <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> On Sat, 2005-04-23 at 03:42 -0400, Chip Turner wrote: > Warren Togami writes: > > > Ville Skytt? wrote: > >> On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote: > >> > >>> CPAN+ can build debian packages with CPANPLUS::Dist. Would it be > >>> worthwhile creating an RPM target? > >> Would it offer something that cpan2rpm or RPM-Specfile already don't? > >> > > > > https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list > > Chip has expressed that he wants to fix cpanflute2 (shipped in Core) > > to do exactly what we want. Let's get him on this list. Hey Chip > > this is the Fedora Project perl team's devel list. I aim to keep list > > traffic here low noise through strict moderation and zero tolerance > > for bullshit. > > > > While cpanflute2 writing specs closer to the Fedora Project perl spec > > template would help us, it will never be a fully automated > > process. Each package needs to be analyzed to disable part or whole of > > "make test" because it is inappropriate to run network tests in the > > build system. Other packages need to be told the location of other > > non-perl software and stuff. > > Hi guys! > > Sorry for the late response. Been a busy couple weeks (new job, moved > across country, all those convenient excuses). > > I am indeed happy to improve RPM-Specfile in whatever ways we can > brainstorm and in whatever ways will help Fedora. Right now, the > source is embedded in the middle of my own personal subversion repo, > but I can split it out into something more public if people are > interested. > > I've read over the archives (still waiting for moderator approval to > join), but as far as RPM-Specfile's general use... well, it's always > been intended to work on RHL/RHEL/Fedora. I'm not aware of anyone who > really used it on other distros. That's not to say I would blindly > make it forever incompatible with other distros, but the priority has > always been supporting RHEL/Fedora and so I'm comfortable keeping > along that same path. > > I agree also that just packaging every tarball is a bad > idea... there's a lot of bad stuff on CPAN. But, ideally, it should > be as simple as saying 'make an rpm of Fritzy-Blip' and it happens, so > that we can rapidly package as much interesting stuff as possible. > > So... what do we need cpanflute2 to do better? I didn't get around to replying to Ville's email ( https://www.redhat.com/archives/fedora-perl-devel-list/2005- April/msg00006.html ), but I agree with him and Chip. I don't think we should just blindly package everything on CPAN, but we should make it as easy as possible to package and review the stuff that we want. Here are some ideas off the top of my head: * Have cpanflute2 discover if the package is noarch or not, and set up the %build, %install, and %files sections accordingly. * Have cpanflute2 query CPAN to automatically fill in %version, %URL, %Source0 * Have cpanflute2 look for common doc files and add them to %docs The workflow I picture is: $ cpanflute2 Test::AutoBuild ... looking up Test::AutoBuild ... downloading Test::AutoBuild-1.0.3 ... examining Test-AutoBuild-1.0.3.tar.gz ... writing perl-Test-AutoBuild.spec $ emacs perl-Test-AutoBuild.spec This is similar to Ville's process. I'm just wondering how many of the 'blanks' we can fill in automatically. Apologies in advance if any of these features are already implemented. Cheers -- Dennis From cturner at pattern.net Tue Apr 26 04:38:48 2005 From: cturner at pattern.net (Chip Turner) Date: Tue, 26 Apr 2005 00:38:48 -0400 Subject: Well here we are In-Reply-To: <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> (Dennis Gregorovic's message of "Mon, 25 Apr 2005 13:04:48 -0400") References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> Message-ID: Dennis Gregorovic writes: > Here are some ideas off the top of my head: > * Have cpanflute2 discover if the package is noarch or not, and set up > the %build, %install, and %files sections accordingly. If you have perl-Archive-Tar and perl-Compress-Zlib (or is it perl-IO-Zlib these days?) installed, it will already do this. It is a lousy heuristic (walk the tarball, see if ther are any .xs, .c, or .h files), but in practice it works pretty much 100%. > * Have cpanflute2 query CPAN to automatically fill in %version, %URL, > %Source0 It should automatically fill in version, but cpanflute2 operates from the tarball, so it bases it on the version in the tarball's filename. > * Have cpanflute2 look for common doc files and add them to %docs It already does this too. It relies on the 'make install' of the perl module to copy them, but it does flag a variety of commonly named files as %doc. > The workflow I picture is: > $ cpanflute2 Test::AutoBuild > ... looking up Test::AutoBuild > ... downloading Test::AutoBuild-1.0.3 > ... examining Test-AutoBuild-1.0.3.tar.gz > ... writing perl-Test-AutoBuild.spec > $ emacs perl-Test-AutoBuild.spec > Ah, this is the rub. Right now, cpanflute2 operates on an already-provided tarball. You have to download it on your own. Downloading from CPAN is, unfortunately, not an entirely clean operation. At least, it wasn't last time I looked. You need to worry about mirrors, and about finding a module by a given name, etc. Unfortunately, as of now, there isn't a very clean way to do that from what I understand. cpan2rpm jumps through several different hoops to download packages; I'm just not sure that it is the right thing to do inside of cpanflute2. It is the area they can definitely say they are better, but I'm not sure I like the price of meeting them there. > This is similar to Ville's process. I'm just wondering how many of the > 'blanks' we can fill in automatically. > > Apologies in advance if any of these features are already implemented. No problem! Not like there is a page listing cpanflute2's features anyway :) Chip -- Chip Turner cturner at pattern.net From shiva at sewingwitch.com Wed Apr 27 14:35:23 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 27 Apr 2005 07:35:23 -0700 Subject: Overriding core Perl modules Message-ID: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> This has already been touched on in a couple of other threads, more as a matter of figuring out which modules should be removed from core and made separate packages. A different approach is to use the site mechanism and library path or some extension of it to allow replacement modules to coexist with those in core. Using cpanflute2 one can use "--installdirs=site" to create a package that installs to the site directories instead of the vendor directories. This is almost sufficient to do the job, but there's no "site" directory for man pages, so one will get install-time conflicts for those. My own involvement is in installing MIMEDefang (http://mimedefang.org/), which requires a raft of Perl modules, some of which are updates to those in core. Most were easy enough to repackage with cpanflute2, but a couple required a bit of intervention to deal with unusual tarball names and conflicts with Perl core packaging. From shiva at sewingwitch.com Wed Apr 27 14:45:42 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 27 Apr 2005 07:45:42 -0700 Subject: cpanflute2 enhancements (was: Well here we are) In-Reply-To: References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> Message-ID: <02F549F4F01873A74EAF8D29@[10.169.6.246]> --On Tuesday, April 26, 2005 12:38 AM -0400 Chip Turner wrote: > It should automatically fill in version, but cpanflute2 operates from > the tarball, so it bases it on the version in the tarball's filename. I'd definitely like to see cpanflute2 be a bit smarter about package/directory/tarball names. I'd like to see it peek inside the tarball directory structure to cook up the right %setup directive, allowing the tarball name to have no relation to the BUILD directory name. Until recently I needed a patched version of MIME::tools that came in a file named MIME-tools-5.411a-RP-Patched-3.tar.gz which confused cpanflute2 badly. (The package has since been adopted by the MIMEDefang maintainer and has a more reasonable tarball filename.) > Downloading from CPAN is, unfortunately, not an entirely clean > operation. What does CPAN.pm do to accomplish this? I recently needed to install CGI::Builder and after a brief attempt at using cpanflute2, I gave up and went to /usr/bin/cpan to install the associated Bundle module. It would be great if some kind RPM mechanism was available to do the equivalent. From cturner at pattern.net Wed Apr 27 15:43:04 2005 From: cturner at pattern.net (Chip Turner) Date: Wed, 27 Apr 2005 11:43:04 -0400 Subject: Overriding core Perl modules In-Reply-To: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> (Kenneth Porter's message of "Wed, 27 Apr 2005 07:35:23 -0700") References: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> Message-ID: Kenneth Porter writes: > This has already been touched on in a couple of other threads, more as > a matter of figuring out which modules should be removed from core and > made separate packages. A different approach is to use the site > mechanism and library path or some extension of it to allow > replacement modules to coexist with those in core. Yep, this option works too, except that upgrading to a new Perl would still use the old module. Probably okay. (or is rawhide set so that site_perl comes before vendor_perl and even the local perl's dirs, now? I think I fixed that, not sure) > Using cpanflute2 one can use "--installdirs=site" to create a package > that installs to the site directories instead of the vendor > directories. This is almost sufficient to do the job, but there's no > "site" directory for man pages, so one will get install-time conflicts > for those. > > Yeah, the man page thing is a royally frustrating part. The FHS uncertainty is one of the things that kept me from fixing this before; it doesn't seem right to throw it over in /usr/local/share/man, but otherwise you get conflicts. Given /usr/local is meant for site customization, perhaps it is okay to mix that in with site_perl since site_perl is meant for site customization. Hmm. Fixing this ultimately is a bug in perl, as 142837 identified... fix perl and cpanflute2 will be fixed, too, though it is possible to work around it with cpanflute2. But hey, I could change cpanflute2 to at least offer a --local-manpages option un the meantime, til perl is fixed, that would move whatever was in /usr/man to /usr/local/man; would that suffice? Chip -- Chip Turner cturner at pattern.net From cturner at pattern.net Wed Apr 27 15:51:17 2005 From: cturner at pattern.net (Chip Turner) Date: Wed, 27 Apr 2005 11:51:17 -0400 Subject: cpanflute2 enhancements In-Reply-To: <02F549F4F01873A74EAF8D29@[10.169.6.246]> (Kenneth Porter's message of "Wed, 27 Apr 2005 07:45:42 -0700") References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> <02F549F4F01873A74EAF8D29@[10.169.6.246]> Message-ID: Kenneth Porter writes: > --On Tuesday, April 26, 2005 12:38 AM -0400 Chip Turner > wrote: > >> It should automatically fill in version, but cpanflute2 operates from >> the tarball, so it bases it on the version in the tarball's filename. > > I'd definitely like to see cpanflute2 be a bit smarter about > package/directory/tarball names. I'd like to see it peek inside the > tarball directory structure to cook up the right %setup directive, > allowing the tarball name to have no relation to the BUILD directory > name. > > Until recently I needed a patched version of MIME::tools that came in > a file named MIME-tools-5.411a-RP-Patched-3.tar.gz which confused > cpanflute2 badly. (The package has since been adopted by the > MIMEDefang maintainer and has a more reasonable tarball filename.) Your wish is my command. cpanflute2 will now inspect the tarball (assuming it can; gotta have perl-Archive-Tar and perl-IO-Zlib). If the first directory of every file in the tarball is consistent, then that is what will be passed to %setup (with the version replaced with %{version}, if possible). It falls back to the old behavior if it cannot determine a common prefix. Will this suffice for your needs? >> Downloading from CPAN is, unfortunately, not an entirely clean >> operation. > > What does CPAN.pm do to accomplish this? Lots. Remember the first time you installed CPAN.pm and it found mirrors, used about six differnt modules to download from, prompted you for lots of info, etc? It left its droppings in ~/.cpan of all the decisions it made. In essence, basically you have to download an index of cpan and inspect it to find what the latest version of a module is, and then find the path to it. There seems to be no API to do this cleanly against, say, search.cpan.org. I've submitted a nebulous feature request to s.c.o, but no telling how/when/if that will work. > I recently needed to install CGI::Builder and after a brief attempt at > using cpanflute2, I gave up and went to /usr/bin/cpan to install the > associated Bundle module. It would be great if some kind RPM mechanism > was available to do the equivalent. > > Was what was blocking you the manpage thing and the %setup directory, or something else? Chip -- Chip Turner cturner at pattern.net From shiva at sewingwitch.com Wed Apr 27 16:02:03 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 27 Apr 2005 09:02:03 -0700 Subject: Overriding core Perl modules In-Reply-To: References: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> Message-ID: --On Wednesday, April 27, 2005 11:43 AM -0400 Chip Turner wrote: > Yep, this option works too, except that upgrading to a new Perl would > still use the old module. Probably okay. (or is rawhide set so that > site_perl comes before vendor_perl and even the local perl's dirs, > now? I think I fixed that, not sure) That would be nice. Currently (FC2 for me) one must issue a "use lib" in code that needs to override builtins with site libs. > But hey, I could change cpanflute2 to at least offer a > --local-manpages option un the meantime, til perl is fixed, that would > move whatever was in /usr/man to /usr/local/man; would that suffice? That would be a good interim workaround until Perl and FHS figure out the Right Thing. From shiva at sewingwitch.com Wed Apr 27 16:16:54 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 27 Apr 2005 09:16:54 -0700 Subject: cpanflute2 enhancements In-Reply-To: References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> <02F549F4F01873A74EAF8D29@[10.169.6.246]> Message-ID: <24A9F713A209D3CAAB630137@[10.169.6.246]> --On Wednesday, April 27, 2005 11:51 AM -0400 Chip Turner wrote: > Your wish is my command. cpanflute2 will now inspect the tarball > (assuming it can; gotta have perl-Archive-Tar and perl-IO-Zlib). If > the first directory of every file in the tarball is consistent, then > that is what will be passed to %setup (with the version replaced with > %{version}, if possible). It falls back to the old behavior if it > cannot determine a common prefix. Will this suffice for your needs? Thanks, that's great! >> > r/Complete.pm> > > Was what was blocking you the manpage thing and the %setup directory, > or something else? More the sheer number of packages and the entwined dependency tree to build it all. With RPM I have to download and package something, discover the dependency, download, package and install the dependency, then discover its dependencies.... All intertwined with su'ing between my packaging mortal and root. Very tedious. At least with Perl modules I don't need to worry about inspecting %pre/%post scripts, but I do worry that a rogue Makefile could do something bad as root. I'd rather do all the packaging as a mortal and then install everything from RPM packages as root. (Makefiles can silently overwrite things, while RPM will block the install on conflicts, and will record everything that it installs.) I suppose it would be acceptable if an automated mechanism sudo'd to install the dependencies as they were packaged. (Of course CPAN.pm has the problem that it must run as root to make and install all the dependencies along the way, so packaging RPM's as root would be no worse than what we have now.) From ville.skytta at iki.fi Wed Apr 27 16:43:37 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 27 Apr 2005 19:43:37 +0300 Subject: Overriding core Perl modules In-Reply-To: References: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> Message-ID: <1114620217.16489.85.camel@bobcat.mine.nu> On Wed, 2005-04-27 at 11:43 -0400, Chip Turner wrote: > Yeah, the man page thing is a royally frustrating part. The FHS > uncertainty is one of the things that kept me from fixing this before; > it doesn't seem right to throw it over in /usr/local/share/man, but > otherwise you get conflicts. Given /usr/local is meant for site > customization, perhaps it is okay to mix that in with site_perl since > site_perl is meant for site customization. I think prefixing the whole site_perl hierarchy to /usr/local would be good. Implementing that could get somewhat messy though: it shouldn't be just declared that site_perl below /usr/lib/perl5 is no longer in @INC, but compat symlinks would have to be provided. But the site_perl dirs below /usr/lib/perl5 cannot be overwritten with symlinks on upgrades... In the FHS sense, I don't think the site_perl relocation would be a problem per se. It could be seen as a problem in non-locally packaged Perl modules that install therein though, but that's not a showstopper for the relocation plan IMO. > But hey, I could change cpanflute2 to at least offer a > --local-manpages option un the meantime, til perl is fixed, that would > move whatever was in /usr/man to /usr/local/man; would that suffice? Hm, is there a "/share" missing before "/man" in both paths above? From shiva at sewingwitch.com Wed Apr 27 17:24:54 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 27 Apr 2005 10:24:54 -0700 Subject: Overriding core Perl modules In-Reply-To: <1114620217.16489.85.camel@bobcat.mine.nu> References: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> <1114620217.16489.85.camel@bobcat.mine.nu> Message-ID: <481C18B70735CAB7FEB97328@[10.169.6.246]> --On Wednesday, April 27, 2005 7:43 PM +0300 VilleSkytt? wrote: > I think prefixing the whole site_perl hierarchy to /usr/local would be > good. Are you equating site_perl to /usr/local, then? I think of the latter as a place to put unpackaged stuff, so I'd still want a place to put packaged Perl modules that don't come with core or that override it with newer components. From ville.skytta at iki.fi Wed Apr 27 20:31:15 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 27 Apr 2005 23:31:15 +0300 Subject: Overriding core Perl modules In-Reply-To: <481C18B70735CAB7FEB97328@[10.169.6.246]> References: <1DE837FA04C1837649B9AFC8@[10.169.6.246]> <1114620217.16489.85.camel@bobcat.mine.nu> <481C18B70735CAB7FEB97328@[10.169.6.246]> Message-ID: <1114633875.16489.104.camel@bobcat.mine.nu> On Wed, 2005-04-27 at 10:24 -0700, Kenneth Porter wrote: > --On Wednesday, April 27, 2005 7:43 PM +0300 VilleSkytt? > wrote: > > > I think prefixing the whole site_perl hierarchy to /usr/local would be > > good. > > Are you equating site_perl to /usr/local, then? Not equating, but prefixing. But we probably talk about the same thing, ie. /usr/local/lib/perl5/site_perl, /usr/local/share/man, /usr/local/bin. > I think of the latter as a > place to put unpackaged stuff, so I'd still want a place to put packaged > Perl modules that don't come with core or that override it with newer > components. I don't think there is anything wrong with installing *local* stuff into /usr/local (packaged or not), that's what the /usr/local hierarchy exists for anyway. That would help with the "override core" part. For stuff that isn't shipping in the repositories one uses, there would be the choice of using vendor (or site) install dirs. From wtogami at redhat.com Thu Apr 28 03:32:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Apr 2005 17:32:05 -1000 Subject: FC3 perl update coming Message-ID: <42705935.7040105@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156128 FC3 perl update coming soon. This is your last chance to add obviously correct fixes to FC3 (and FC4) perl before we push the FC3 update for security reasons. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148847 This at least gives us an opportunity to push the FCGI fix that Rob has been crying about. I suspect that the FC4 perl package would be fine to push as the FC3 update if we remove the CGI version upgrade. We of course need to do some verification and testing here before doing it. Warren Togami wtogami at redhat.com From jefffearn at gmail.com Fri Apr 29 00:42:16 2005 From: jefffearn at gmail.com (Jeff Fearn) Date: Fri, 29 Apr 2005 10:42:16 +1000 Subject: cpanflute2 enhancements In-Reply-To: References: <42634750.9060000@redhat.com> <1113805918.2607.55.camel@bobcat.mine.nu> <426356A6.6010508@redhat.com> <1114448688.5118.38.camel@dhcp83-103.boston.redhat.com> <02F549F4F01873A74EAF8D29@10.169.6.246> Message-ID: <2411051405042817426eeefde3@mail.gmail.com> On 4/28/05, Chip Turner wrote: > >> Downloading from CPAN is, unfortunately, not an entirely clean > >> operation. > > > > What does CPAN.pm do to accomplish this? > > Lots. Remember the first time you installed CPAN.pm and it found > mirrors, used about six differnt modules to download from, prompted > you for lots of info, etc? It left its droppings in ~/.cpan of all > the decisions it made. In essence, basically you have to download an > index of cpan and inspect it to find what the latest version of a > module is, and then find the path to it. There seems to be no API to > do this cleanly against, say, search.cpan.org. I've submitted a > nebulous feature request to s.c.o, but no telling how/when/if that > will work. You can use CPAN to do this, here is some code I wrote to try and make cpan2rpm recursively get modules from cpan, rpmbuild and the install the rpm. It works fine on modules but did not work for distributions, I believe this failure may be due to me having a mixed threaded/non-threaded perl install . Hopefully this may help you. This assumes you have CPAN setup, I ran the cpan shell and set it up, no modules where installed using CPAN though. Also requires a few CPAN modules, like CPAN::Dependency. --snip cpan2rpm code --- my $name = $info->{dist}; my $obj; if($CPAN::META->exists('CPAN::Module',$name)){ cpan_get_deps($info, $name); } elsif($obj = CPAN::Shell->expand("Distribution", "\/$name\/")){ die("Distributions not handled yet: $name\n"); # may work on proper perl installs } elsif($obj = CPAN::Shell->expand("Bundle", "\/$name\/")){ die("Bundles not handled yet: $name\n"); } else{ die("Unknow type for $name\n"); } --end snip cpan2rpm code --- # Get the dependencies for a module sub cpan_get_deps { my $info = shift; my $name = shift || die("cpan_get_mod needs a name!\n"); use CPAN::Dependency; my $cpandeps = CPAN::Dependency->new(process => $name); $cpandeps->run; # this may take some time.. foreach my $modl ($cpandeps->deps_by_dists()) { foreach my $parent (keys(%$modl)){ foreach my $name (keys(%{$modl->{$parent}->{prereqs}})) { $name =~ s/-/::/g; $name =~ s/.pm//; eval("use $name"); if($@){ cpan_get_mod($info, $name); } } } } } # Fetch a module sub cpan_get_mod { my $info = shift; my $name = shift || die("cpan_get_mod needs a name!\n"); my $module = CPAN::Shell->expand("Module", $name) || die("Could not handle $name\n"); my $version = $module->cpan_version; $module->get; my $auth = CPAN::Shell->expand('Author', $module->userid); my $author = $auth->fullname; my @args=("cpan2rpm"); if($info{install}){ push(@args, "-i"); } @args = (@args, "--author '$author'", "--version '$version'", $CPAN::Config->{cpan_home} . '/sources/authors/id/' . $module->cpan_file); my $cmd = join(" ", @args); if(system($cmd) != 0){die("Could not process module: $name");} chdir $info->{evaldir} || die "get_meta(): $!"; return(0); } Jeff Fearn From wtogami at redhat.com Fri Apr 29 02:16:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 28 Apr 2005 16:16:53 -1000 Subject: FC3 perl update coming In-Reply-To: <42705935.7040105@redhat.com> References: <42705935.7040105@redhat.com> Message-ID: <42719915.7020908@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156288 Apparently a FC3 perl update was pushed yesterday, and due to a rel-eng problem is clashing and blocking updates on x86-64. http://people.redhat.com/wtogami/temp/perl-FC3/ http://people.redhat.com/wtogami/temp/perl-FC4/ Built test packages with the security fix and other stuff. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148847 Rob indicated that the FC3 package above actually does NOT fix the FCGI problem. Can somebody investigate? Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Apr 29 02:41:44 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 28 Apr 2005 16:41:44 -1000 Subject: FC3 perl update coming In-Reply-To: <42719915.7020908@redhat.com> References: <42705935.7040105@redhat.com> <42719915.7020908@redhat.com> Message-ID: <42719EE8.8050705@redhat.com> Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156288 > > Apparently a FC3 perl update was pushed yesterday, and due to a rel-eng > problem is clashing and blocking updates on x86-64. > Oh crap. perl.i386 was never meant to be pushed in the original distro of FC3 and RHEL4, and users need to remove it manually on both in order to upgrade. Not a great situation... but spread the word. 'yum remove perl.i386' should do the trick. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Apr 29 18:41:04 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 29 Apr 2005 08:41:04 -1000 Subject: FC3 perl update coming In-Reply-To: <42719915.7020908@redhat.com> References: <42705935.7040105@redhat.com> <42719915.7020908@redhat.com> Message-ID: <42727FC0.9040805@redhat.com> Warren Togami wrote: > > http://people.redhat.com/wtogami/temp/perl-FC3/ > http://people.redhat.com/wtogami/temp/perl-FC4/ Anybody else tested it? Should we push this update? Warren