Commit | Line | Data |
---|---|---|
920dae64 AT |
1 | .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32 |
2 | .\" | |
3 | .\" Standard preamble: | |
4 | .\" ======================================================================== | |
5 | .de Sh \" Subsection heading | |
6 | .br | |
7 | .if t .Sp | |
8 | .ne 5 | |
9 | .PP | |
10 | \fB\\$1\fR | |
11 | .PP | |
12 | .. | |
13 | .de Sp \" Vertical space (when we can't use .PP) | |
14 | .if t .sp .5v | |
15 | .if n .sp | |
16 | .. | |
17 | .de Vb \" Begin verbatim text | |
18 | .ft CW | |
19 | .nf | |
20 | .ne \\$1 | |
21 | .. | |
22 | .de Ve \" End verbatim text | |
23 | .ft R | |
24 | .fi | |
25 | .. | |
26 | .\" Set up some character translations and predefined strings. \*(-- will | |
27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left | |
28 | .\" double quote, and \*(R" will give a right double quote. | will give a | |
29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to | |
30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' | |
31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. | |
32 | .tr \(*W-|\(bv\*(Tr | |
33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' | |
34 | .ie n \{\ | |
35 | . ds -- \(*W- | |
36 | . ds PI pi | |
37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch | |
38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch | |
39 | . ds L" "" | |
40 | . ds R" "" | |
41 | . ds C` "" | |
42 | . ds C' "" | |
43 | 'br\} | |
44 | .el\{\ | |
45 | . ds -- \|\(em\| | |
46 | . ds PI \(*p | |
47 | . ds L" `` | |
48 | . ds R" '' | |
49 | 'br\} | |
50 | .\" | |
51 | .\" If the F register is turned on, we'll generate index entries on stderr for | |
52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index | |
53 | .\" entries marked with X<> in POD. Of course, you'll have to process the | |
54 | .\" output yourself in some meaningful fashion. | |
55 | .if \nF \{\ | |
56 | . de IX | |
57 | . tm Index:\\$1\t\\n%\t"\\$2" | |
58 | .. | |
59 | . nr % 0 | |
60 | . rr F | |
61 | .\} | |
62 | .\" | |
63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes | |
64 | .\" way too many mistakes in technical documents. | |
65 | .hy 0 | |
66 | .if n .na | |
67 | .\" | |
68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). | |
69 | .\" Fear. Run. Save yourself. No user-serviceable parts. | |
70 | . \" fudge factors for nroff and troff | |
71 | .if n \{\ | |
72 | . ds #H 0 | |
73 | . ds #V .8m | |
74 | . ds #F .3m | |
75 | . ds #[ \f1 | |
76 | . ds #] \fP | |
77 | .\} | |
78 | .if t \{\ | |
79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) | |
80 | . ds #V .6m | |
81 | . ds #F 0 | |
82 | . ds #[ \& | |
83 | . ds #] \& | |
84 | .\} | |
85 | . \" simple accents for nroff and troff | |
86 | .if n \{\ | |
87 | . ds ' \& | |
88 | . ds ` \& | |
89 | . ds ^ \& | |
90 | . ds , \& | |
91 | . ds ~ ~ | |
92 | . ds / | |
93 | .\} | |
94 | .if t \{\ | |
95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" | |
96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' | |
97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' | |
98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' | |
99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' | |
100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' | |
101 | .\} | |
102 | . \" troff and (daisy-wheel) nroff accents | |
103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' | |
104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' | |
105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] | |
106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' | |
107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' | |
108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] | |
109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] | |
110 | .ds ae a\h'-(\w'a'u*4/10)'e | |
111 | .ds Ae A\h'-(\w'A'u*4/10)'E | |
112 | . \" corrections for vroff | |
113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' | |
114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' | |
115 | . \" for low resolution devices (crt and lpr) | |
116 | .if \n(.H>23 .if \n(.V>19 \ | |
117 | \{\ | |
118 | . ds : e | |
119 | . ds 8 ss | |
120 | . ds o a | |
121 | . ds d- d\h'-1'\(ga | |
122 | . ds D- D\h'-1'\(hy | |
123 | . ds th \o'bp' | |
124 | . ds Th \o'LP' | |
125 | . ds ae ae | |
126 | . ds Ae AE | |
127 | .\} | |
128 | .rm #[ #] #H #V #F C | |
129 | .\" ======================================================================== | |
130 | .\" | |
131 | .IX Title "PERLHACK 1" | |
132 | .TH PERLHACK 1 "2006-01-07" "perl v5.8.8" "Perl Programmers Reference Guide" | |
133 | .SH "NAME" | |
134 | perlhack \- How to hack at the Perl internals | |
135 | .SH "DESCRIPTION" | |
136 | .IX Header "DESCRIPTION" | |
137 | This document attempts to explain how Perl development takes place, | |
138 | and ends with some suggestions for people wanting to become bona fide | |
139 | porters. | |
140 | .PP | |
141 | The perl5\-porters mailing list is where the Perl standard distribution | |
142 | is maintained and developed. The list can get anywhere from 10 to 150 | |
143 | messages a day, depending on the heatedness of the debate. Most days | |
144 | there are two or three patches, extensions, features, or bugs being | |
145 | discussed at a time. | |
146 | .PP | |
147 | A searchable archive of the list is at either: | |
148 | .PP | |
149 | .Vb 1 | |
150 | \& http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ | |
151 | .Ve | |
152 | .PP | |
153 | or | |
154 | .PP | |
155 | .Vb 1 | |
156 | \& http://archive.develooper.com/perl5-porters@perl.org/ | |
157 | .Ve | |
158 | .PP | |
159 | List subscribers (the porters themselves) come in several flavours. | |
160 | Some are quiet curious lurkers, who rarely pitch in and instead watch | |
161 | the ongoing development to ensure they're forewarned of new changes or | |
162 | features in Perl. Some are representatives of vendors, who are there | |
163 | to make sure that Perl continues to compile and work on their | |
164 | platforms. Some patch any reported bug that they know how to fix, | |
165 | some are actively patching their pet area (threads, Win32, the regexp | |
166 | engine), while others seem to do nothing but complain. In other | |
167 | words, it's your usual mix of technical people. | |
168 | .PP | |
169 | Over this group of porters presides Larry Wall. He has the final word | |
170 | in what does and does not change in the Perl language. Various | |
171 | releases of Perl are shepherded by a \*(L"pumpking\*(R", a porter | |
172 | responsible for gathering patches, deciding on a patch\-by\-patch, | |
173 | feature-by-feature basis what will and will not go into the release. | |
174 | For instance, Gurusamy Sarathy was the pumpking for the 5.6 release of | |
175 | Perl, and Jarkko Hietaniemi was the pumpking for the 5.8 release, and | |
176 | Rafael Garcia-Suarez holds the pumpking crown for the 5.10 release. | |
177 | .PP | |
178 | In addition, various people are pumpkings for different things. For | |
179 | instance, Andy Dougherty and Jarkko Hietaniemi did a grand job as the | |
180 | \&\fIConfigure\fR pumpkin up till the 5.8 release. For the 5.10 release | |
181 | H.Merijn Brand took over. | |
182 | .PP | |
183 | Larry sees Perl development along the lines of the \s-1US\s0 government: | |
184 | there's the Legislature (the porters), the Executive branch (the | |
185 | pumpkings), and the Supreme Court (Larry). The legislature can | |
186 | discuss and submit patches to the executive branch all they like, but | |
187 | the executive branch is free to veto them. Rarely, the Supreme Court | |
188 | will side with the executive branch over the legislature, or the | |
189 | legislature over the executive branch. Mostly, however, the | |
190 | legislature and the executive branch are supposed to get along and | |
191 | work out their differences without impeachment or court cases. | |
192 | .PP | |
193 | You might sometimes see reference to Rule 1 and Rule 2. Larry's power | |
194 | as Supreme Court is expressed in The Rules: | |
195 | .IP "1" 4 | |
196 | .IX Item "1" | |
197 | Larry is always by definition right about how Perl should behave. | |
198 | This means he has final veto power on the core functionality. | |
199 | .IP "2" 4 | |
200 | .IX Item "2" | |
201 | Larry is allowed to change his mind about any matter at a later date, | |
202 | regardless of whether he previously invoked Rule 1. | |
203 | .PP | |
204 | Got that? Larry is always right, even when he was wrong. It's rare | |
205 | to see either Rule exercised, but they are often alluded to. | |
206 | .PP | |
207 | New features and extensions to the language are contentious, because | |
208 | the criteria used by the pumpkings, Larry, and other porters to decide | |
209 | which features should be implemented and incorporated are not codified | |
210 | in a few small design goals as with some other languages. Instead, | |
211 | the heuristics are flexible and often difficult to fathom. Here is | |
212 | one person's list, roughly in decreasing order of importance, of | |
213 | heuristics that new features have to be weighed against: | |
214 | .IP "Does concept match the general goals of Perl?" 4 | |
215 | .IX Item "Does concept match the general goals of Perl?" | |
216 | These haven't been written anywhere in stone, but one approximation | |
217 | is: | |
218 | .Sp | |
219 | .Vb 5 | |
220 | \& 1. Keep it fast, simple, and useful. | |
221 | \& 2. Keep features/concepts as orthogonal as possible. | |
222 | \& 3. No arbitrary limits (platforms, data sizes, cultures). | |
223 | \& 4. Keep it open and exciting to use/patch/advocate Perl everywhere. | |
224 | \& 5. Either assimilate new technologies, or build bridges to them. | |
225 | .Ve | |
226 | .IP "Where is the implementation?" 4 | |
227 | .IX Item "Where is the implementation?" | |
228 | All the talk in the world is useless without an implementation. In | |
229 | almost every case, the person or people who argue for a new feature | |
230 | will be expected to be the ones who implement it. Porters capable | |
231 | of coding new features have their own agendas, and are not available | |
232 | to implement your (possibly good) idea. | |
233 | .IP "Backwards compatibility" 4 | |
234 | .IX Item "Backwards compatibility" | |
235 | It's a cardinal sin to break existing Perl programs. New warnings are | |
236 | contentious\*(--some say that a program that emits warnings is not | |
237 | broken, while others say it is. Adding keywords has the potential to | |
238 | break programs, changing the meaning of existing token sequences or | |
239 | functions might break programs. | |
240 | .IP "Could it be a module instead?" 4 | |
241 | .IX Item "Could it be a module instead?" | |
242 | Perl 5 has extension mechanisms, modules and \s-1XS\s0, specifically to avoid | |
243 | the need to keep changing the Perl interpreter. You can write modules | |
244 | that export functions, you can give those functions prototypes so they | |
245 | can be called like built-in functions, you can even write \s-1XS\s0 code to | |
246 | mess with the runtime data structures of the Perl interpreter if you | |
247 | want to implement really complicated things. If it can be done in a | |
248 | module instead of in the core, it's highly unlikely to be added. | |
249 | .IP "Is the feature generic enough?" 4 | |
250 | .IX Item "Is the feature generic enough?" | |
251 | Is this something that only the submitter wants added to the language, | |
252 | or would it be broadly useful? Sometimes, instead of adding a feature | |
253 | with a tight focus, the porters might decide to wait until someone | |
254 | implements the more generalized feature. For instance, instead of | |
255 | implementing a \*(L"delayed evaluation\*(R" feature, the porters are waiting | |
256 | for a macro system that would permit delayed evaluation and much more. | |
257 | .IP "Does it potentially introduce new bugs?" 4 | |
258 | .IX Item "Does it potentially introduce new bugs?" | |
259 | Radical rewrites of large chunks of the Perl interpreter have the | |
260 | potential to introduce new bugs. The smaller and more localized the | |
261 | change, the better. | |
262 | .IP "Does it preclude other desirable features?" 4 | |
263 | .IX Item "Does it preclude other desirable features?" | |
264 | A patch is likely to be rejected if it closes off future avenues of | |
265 | development. For instance, a patch that placed a true and final | |
266 | interpretation on prototypes is likely to be rejected because there | |
267 | are still options for the future of prototypes that haven't been | |
268 | addressed. | |
269 | .IP "Is the implementation robust?" 4 | |
270 | .IX Item "Is the implementation robust?" | |
271 | Good patches (tight code, complete, correct) stand more chance of | |
272 | going in. Sloppy or incorrect patches might be placed on the back | |
273 | burner until the pumpking has time to fix, or might be discarded | |
274 | altogether without further notice. | |
275 | .IP "Is the implementation generic enough to be portable?" 4 | |
276 | .IX Item "Is the implementation generic enough to be portable?" | |
277 | The worst patches make use of a system-specific features. It's highly | |
278 | unlikely that nonportable additions to the Perl language will be | |
279 | accepted. | |
280 | .IP "Is the implementation tested?" 4 | |
281 | .IX Item "Is the implementation tested?" | |
282 | Patches which change behaviour (fixing bugs or introducing new features) | |
283 | must include regression tests to verify that everything works as expected. | |
284 | Without tests provided by the original author, how can anyone else changing | |
285 | perl in the future be sure that they haven't unwittingly broken the behaviour | |
286 | the patch implements? And without tests, how can the patch's author be | |
287 | confident that his/her hard work put into the patch won't be accidentally | |
288 | thrown away by someone in the future? | |
289 | .IP "Is there enough documentation?" 4 | |
290 | .IX Item "Is there enough documentation?" | |
291 | Patches without documentation are probably ill-thought out or | |
292 | incomplete. Nothing can be added without documentation, so submitting | |
293 | a patch for the appropriate manpages as well as the source code is | |
294 | always a good idea. | |
295 | .IP "Is there another way to do it?" 4 | |
296 | .IX Item "Is there another way to do it?" | |
297 | Larry said "Although the Perl Slogan is \fIThere's More Than One Way | |
298 | to Do It\fR, I hesitate to make 10 ways to do something". This is a | |
299 | tricky heuristic to navigate, though\*(--one man's essential addition is | |
300 | another man's pointless cruft. | |
301 | .IP "Does it create too much work?" 4 | |
302 | .IX Item "Does it create too much work?" | |
303 | Work for the pumpking, work for Perl programmers, work for module | |
304 | authors, ... Perl is supposed to be easy. | |
305 | .IP "Patches speak louder than words" 4 | |
306 | .IX Item "Patches speak louder than words" | |
307 | Working code is always preferred to pie-in-the-sky ideas. A patch to | |
308 | add a feature stands a much higher chance of making it to the language | |
309 | than does a random feature request, no matter how fervently argued the | |
310 | request might be. This ties into \*(L"Will it be useful?\*(R", as the fact | |
311 | that someone took the time to make the patch demonstrates a strong | |
312 | desire for the feature. | |
313 | .PP | |
314 | If you're on the list, you might hear the word \*(L"core\*(R" bandied | |
315 | around. It refers to the standard distribution. \*(L"Hacking on the | |
316 | core\*(R" means you're changing the C source code to the Perl | |
317 | interpreter. \*(L"A core module\*(R" is one that ships with Perl. | |
318 | .Sh "Keeping in sync" | |
319 | .IX Subsection "Keeping in sync" | |
320 | The source code to the Perl interpreter, in its different versions, is | |
321 | kept in a repository managed by a revision control system ( which is | |
322 | currently the Perforce program, see http://perforce.com/ ). The | |
323 | pumpkings and a few others have access to the repository to check in | |
324 | changes. Periodically the pumpking for the development version of Perl | |
325 | will release a new version, so the rest of the porters can see what's | |
326 | changed. The current state of the main trunk of repository, and patches | |
327 | that describe the individual changes that have happened since the last | |
328 | public release are available at this location: | |
329 | .PP | |
330 | .Vb 2 | |
331 | \& http://public.activestate.com/pub/apc/ | |
332 | \& ftp://public.activestate.com/pub/apc/ | |
333 | .Ve | |
334 | .PP | |
335 | If you're looking for a particular change, or a change that affected | |
336 | a particular set of files, you may find the \fBPerl Repository Browser\fR | |
337 | useful: | |
338 | .PP | |
339 | .Vb 1 | |
340 | \& http://public.activestate.com/cgi-bin/perlbrowse | |
341 | .Ve | |
342 | .PP | |
343 | You may also want to subscribe to the perl5\-changes mailing list to | |
344 | receive a copy of each patch that gets submitted to the maintenance | |
345 | and development \*(L"branches\*(R" of the perl repository. See | |
346 | http://lists.perl.org/ for subscription information. | |
347 | .PP | |
348 | If you are a member of the perl5\-porters mailing list, it is a good | |
349 | thing to keep in touch with the most recent changes. If not only to | |
350 | verify if what you would have posted as a bug report isn't already | |
351 | solved in the most recent available perl development branch, also | |
352 | known as perl\-current, bleading edge perl, bleedperl or bleadperl. | |
353 | .PP | |
354 | Needless to say, the source code in perl-current is usually in a perpetual | |
355 | state of evolution. You should expect it to be very buggy. Do \fBnot\fR use | |
356 | it for any purpose other than testing and development. | |
357 | .PP | |
358 | Keeping in sync with the most recent branch can be done in several ways, | |
359 | but the most convenient and reliable way is using \fBrsync\fR, available at | |
360 | ftp://rsync.samba.org/pub/rsync/ . (You can also get the most recent | |
361 | branch by \s-1FTP\s0.) | |
362 | .PP | |
363 | If you choose to keep in sync using rsync, there are two approaches | |
364 | to doing so: | |
365 | .IP "rsync'ing the source tree" 4 | |
366 | .IX Item "rsync'ing the source tree" | |
367 | Presuming you are in the directory where your perl source resides | |
368 | and you have rsync installed and available, you can \*(L"upgrade\*(R" to | |
369 | the bleadperl using: | |
370 | .Sp | |
371 | .Vb 1 | |
372 | \& # rsync -avz rsync://public.activestate.com/perl-current/ . | |
373 | .Ve | |
374 | .Sp | |
375 | This takes care of updating every single item in the source tree to | |
376 | the latest applied patch level, creating files that are new (to your | |
377 | distribution) and setting date/time stamps of existing files to | |
378 | reflect the bleadperl status. | |
379 | .Sp | |
380 | Note that this will not delete any files that were in '.' before | |
381 | the rsync. Once you are sure that the rsync is running correctly, | |
382 | run it with the \-\-delete and the \-\-dry\-run options like this: | |
383 | .Sp | |
384 | .Vb 1 | |
385 | \& # rsync -avz --delete --dry-run rsync://public.activestate.com/perl-current/ . | |
386 | .Ve | |
387 | .Sp | |
388 | This will \fIsimulate\fR an rsync run that also deletes files not | |
389 | present in the bleadperl master copy. Observe the results from | |
390 | this run closely. If you are sure that the actual run would delete | |
391 | no files precious to you, you could remove the '\-\-dry\-run' option. | |
392 | .Sp | |
393 | You can than check what patch was the latest that was applied by | |
394 | looking in the file \fB.patch\fR, which will show the number of the | |
395 | latest patch. | |
396 | .Sp | |
397 | If you have more than one machine to keep in sync, and not all of | |
398 | them have access to the \s-1WAN\s0 (so you are not able to rsync all the | |
399 | source trees to the real source), there are some ways to get around | |
400 | this problem. | |
401 | .RS 4 | |
402 | .IP "Using rsync over the \s-1LAN\s0" 4 | |
403 | .IX Item "Using rsync over the LAN" | |
404 | Set up a local rsync server which makes the rsynced source tree | |
405 | available to the \s-1LAN\s0 and sync the other machines against this | |
406 | directory. | |
407 | .Sp | |
408 | From http://rsync.samba.org/README.html : | |
409 | .Sp | |
410 | .Vb 5 | |
411 | \& "Rsync uses rsh or ssh for communication. It does not need to be | |
412 | \& setuid and requires no special privileges for installation. It | |
413 | \& does not require an inetd entry or a daemon. You must, however, | |
414 | \& have a working rsh or ssh system. Using ssh is recommended for | |
415 | \& its security features." | |
416 | .Ve | |
417 | .IP "Using pushing over the \s-1NFS\s0" 4 | |
418 | .IX Item "Using pushing over the NFS" | |
419 | Having the other systems mounted over the \s-1NFS\s0, you can take an | |
420 | active pushing approach by checking the just updated tree against | |
421 | the other not-yet synced trees. An example would be | |
422 | .Sp | |
423 | .Vb 1 | |
424 | \& #!/usr/bin/perl -w | |
425 | .Ve | |
426 | .Sp | |
427 | .Vb 2 | |
428 | \& use strict; | |
429 | \& use File::Copy; | |
430 | .Ve | |
431 | .Sp | |
432 | .Vb 4 | |
433 | \& my %MF = map { | |
434 | \& m/(\eS+)/; | |
435 | \& $1 => [ (stat $1)[2, 7, 9] ]; # mode, size, mtime | |
436 | \& } `cat MANIFEST`; | |
437 | .Ve | |
438 | .Sp | |
439 | .Vb 1 | |
440 | \& my %remote = map { $_ => "/$_/pro/3gl/CPAN/perl-5.7.1" } qw(host1 host2); | |
441 | .Ve | |
442 | .Sp | |
443 | .Vb 18 | |
444 | \& foreach my $host (keys %remote) { | |
445 | \& unless (-d $remote{$host}) { | |
446 | \& print STDERR "Cannot Xsync for host $host\en"; | |
447 | \& next; | |
448 | \& } | |
449 | \& foreach my $file (keys %MF) { | |
450 | \& my $rfile = "$remote{$host}/$file"; | |
451 | \& my ($mode, $size, $mtime) = (stat $rfile)[2, 7, 9]; | |
452 | \& defined $size or ($mode, $size, $mtime) = (0, 0, 0); | |
453 | \& $size == $MF{$file}[1] && $mtime == $MF{$file}[2] and next; | |
454 | \& printf "%4s %-34s %8d %9d %8d %9d\en", | |
455 | \& $host, $file, $MF{$file}[1], $MF{$file}[2], $size, $mtime; | |
456 | \& unlink $rfile; | |
457 | \& copy ($file, $rfile); | |
458 | \& utime time, $MF{$file}[2], $rfile; | |
459 | \& chmod $MF{$file}[0], $rfile; | |
460 | \& } | |
461 | \& } | |
462 | .Ve | |
463 | .Sp | |
464 | though this is not perfect. It could be improved with checking | |
465 | file checksums before updating. Not all \s-1NFS\s0 systems support | |
466 | reliable utime support (when used over the \s-1NFS\s0). | |
467 | .RE | |
468 | .RS 4 | |
469 | .RE | |
470 | .IP "rsync'ing the patches" 4 | |
471 | .IX Item "rsync'ing the patches" | |
472 | The source tree is maintained by the pumpking who applies patches to | |
473 | the files in the tree. These patches are either created by the | |
474 | pumpking himself using \f(CW\*(C`diff \-c\*(C'\fR after updating the file manually or | |
475 | by applying patches sent in by posters on the perl5\-porters list. | |
476 | These patches are also saved and rsync'able, so you can apply them | |
477 | yourself to the source files. | |
478 | .Sp | |
479 | Presuming you are in a directory where your patches reside, you can | |
480 | get them in sync with | |
481 | .Sp | |
482 | .Vb 1 | |
483 | \& # rsync -avz rsync://public.activestate.com/perl-current-diffs/ . | |
484 | .Ve | |
485 | .Sp | |
486 | This makes sure the latest available patch is downloaded to your | |
487 | patch directory. | |
488 | .Sp | |
489 | It's then up to you to apply these patches, using something like | |
490 | .Sp | |
491 | .Vb 5 | |
492 | \& # last=`ls -t *.gz | sed q` | |
493 | \& # rsync -avz rsync://public.activestate.com/perl-current-diffs/ . | |
494 | \& # find . -name '*.gz' -newer $last -exec gzcat {} \e; >blead.patch | |
495 | \& # cd ../perl-current | |
496 | \& # patch -p1 -N <../perl-current-diffs/blead.patch | |
497 | .Ve | |
498 | .Sp | |
499 | or, since this is only a hint towards how it works, use CPAN-patchaperl | |
500 |