Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pod::Html doesn't remove temporary files #9909

Closed
p5pRT opened this issue Oct 15, 2009 · 20 comments
Closed

Pod::Html doesn't remove temporary files #9909

p5pRT opened this issue Oct 15, 2009 · 20 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 15, 2009

Migrated from rt.perl.org#69782 (status was 'resolved')

Searchable as RT69782$

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From jackyf.devel@gmail.com

Created by jackyf.devel@gmail.com

From http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378328​:

pod2html does not remove temporary files before exiting​:

$ ls -a
. ..
$ pod2html /dev/null > /dev/null
$ ls -a
. .. pod2htmd.tmp pod2htmi.tmp

...

The Pod​::Html perl module neglects to remove the temporary files it
created.

Perl Info

Flags:
    category=library
    severity=low
    module=Pod::Html

Site configuration information for perl 5.10.1:

Configured by Debian Project at Thu Oct  1 08:10:39 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.31-trunk-amd64, archname=x86_64-linux-gnu-thread-multi
    uname='linux madeleine 2.6.31-trunk-amd64 #1 smp tue sep 22 22:33:08 eest 2009 x86_64 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.1 -Dsitearch=/usr/local/lib/perl/5.10.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.1 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.3.4', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.9.so, so=so, useshrplib=true, libperl=libperl.so.5.10.1
    gnulibc_version='2.9'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.10.1:
    /etc/perl
    /usr/local/lib/perl/5.10.1
    /usr/local/share/perl/5.10.1
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .


Environment for perl 5.10.1:
    HOME=/home/jackyf
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/jackyf/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From @obra

From http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378328​:

pod2html does not remove temporary files before exiting​:

$ ls -a
. ..
$ pod2html /dev/null > /dev/null
$ ls -a
. .. pod2htmd.tmp pod2htmi.tmp

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From @jandubois

On Thu, 15 Oct 2009, jesse wrote​:

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

I remember that Pod​::Html maintenance was in some kind of stalemate.
David Landgren has been given co-maintainership, and he said (IIRC)
he doesn't want to apply any changes to Pod​::Html until the code has
been refactored, but then Tom Christiansen vetoed changes that would
be for purely stylistic reasons. Nothing much happened after that.

There is one dev release of Pod​::Html on CPAN​:

  http​://search.cpan.org/~dland/Pod-Html-1.09_04/

I've CC'ed David so he can clarify the situation.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From p5p@perl.wizbit.be

Citeren Jan Dubois <jand@​activestate.com>​:

On Thu, 15 Oct 2009, jesse wrote​:

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

I remember that Pod​::Html maintenance was in some kind of stalemate.
David Landgren has been given co-maintainership, and he said (IIRC)
he doesn't want to apply any changes to Pod​::Html until the code has
been refactored, but then Tom Christiansen vetoed changes that would
be for purely stylistic reasons. Nothing much happened after that.

There is one dev release of Pod​::Html on CPAN​:

http&#8203;://search\.cpan\.org/~dland/Pod\-Html\-1\.09\_04/

I've CC'ed David so he can clarify the situation.

From how I remember the situation​:

- David send a patch (on 30 April 2008) with style changes for Pod​::Html
- Tux (H.Merijn Brand) was reluctant to apply it because he remembered
Tom had veto'ed such changed in the past

Tom did not speak up in that discussion.
See also​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2008/04/msg136411.html

On 3 Augustus 2008 I mailed Tom about this and asked him if he was ok
with David becoming the maintainer and changing the style. Tom had no
problems with this.

Quote from Tom​:
"No, I have no plans of maintaining Pod​::Html in the future and yes, I am
more than perfectly OK with David -- or anyone -- taking over the
maintenance and thus changing the style."

Also on 3 Augustus 2008 (after receving Tom's reply) I send a mail to
Tux and David that Tom was Ok with the style change and that the patch
could (/should) be applied to blead.

(Neither Tux nor David responded on that mail)

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.

Best regards,

Bram

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From @jandubois

On Thu, 15 Oct 2009, Bram wrote​:

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.

Ah, excellent.

The point that still needs clarification is if Pod​::Html is considered
to be dual-lifed or not. Right now Porting/Maintainers.pl claims the
module is maintained by P5P. Of course to be properly dual-lifed it
would need a non-dev release to CPAN first. So it would still be good
to hear from David if he intends to maintain Pod​::Html or not, and if
core or cpan should become the upstream. I have not compared the
core and the cpan versions to see if they already diverged significantly,
but if they did, then further patching in the core might delay an
eventual non-dev release to CPAN even more.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From renee.baecker@smart-websolutions.de

Jan Dubois schrieb​:

On Thu, 15 Oct 2009, Bram wrote​:

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.

Ah, excellent.

The point that still needs clarification is if Pod​::Html is considered
to be dual-lifed or not. Right now Porting/Maintainers.pl claims the
module is maintained by P5P. Of course to be properly dual-lifed it
would need a non-dev release to CPAN first. So it would still be good
to hear from David if he intends to maintain Pod​::Html or not, and if
core or cpan should become the upstream. I have not compared the
core and the cpan versions to see if they already diverged significantly,
but if they did, then further patching in the core might delay an
eventual non-dev release to CPAN even more.

When it is dual-lifed, we can browse through rt.perl.org. There are
already other patches for Pod​::Html...

I would help with this...

Cheers,
-Jan

- Renee

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From david@landgren.net

Bram wrote​:

Citeren Jan Dubois <jand@​activestate.com>​:

On Thu, 15 Oct 2009, jesse wrote​:

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

I remember that Pod​::Html maintenance was in some kind of stalemate.
David Landgren has been given co-maintainership, and he said (IIRC)
he doesn't want to apply any changes to Pod​::Html until the code has
been refactored, but then Tom Christiansen vetoed changes that would
be for purely stylistic reasons. Nothing much happened after that.

There is one dev release of Pod​::Html on CPAN​:

http&#8203;://search\.cpan\.org/~dland/Pod\-Html\-1\.09\_04/

I've CC'ed David so he can clarify the situation.

From how I remember the situation​:

- David send a patch (on 30 April 2008) with style changes for Pod​::Html
- Tux (H.Merijn Brand) was reluctant to apply it because he remembered
Tom had veto'ed such changed in the past

Tom did not speak up in that discussion.
See also​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2008/04/msg136411.html

On 3 Augustus 2008 I mailed Tom about this and asked him if he was ok
with David becoming the maintainer and changing the style. Tom had no
problems with this.

Quote from Tom​:
"No, I have no plans of maintaining Pod​::Html in the future and yes, I am
more than perfectly OK with David -- or anyone -- taking over the
maintenance and thus changing the style."

Also on 3 Augustus 2008 (after receving Tom's reply) I send a mail to
Tux and David that Tom was Ok with the style change and that the patch
could (/should) be applied to blead.

(Neither Tux nor David responded on that mail)

That one slipped right under my radar, sorry.

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.

Aha! Well, I doubt I'll make it in time for 5.11.1, but I will resume
working on this then. There are a couple of other tickets to be taken
care of as well.

Thanks,
David

--
The rich and powerful piss on us, and the media tells us it's raining

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From david@landgren.net

Jan Dubois a écrit :

On Thu, 15 Oct 2009, Bram wrote​:

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.

Ah, excellent.

The point that still needs clarification is if Pod​::Html is considered
to be dual-lifed or not. Right now Porting/Maintainers.pl claims the
module is maintained by P5P. Of course to be properly dual-lifed it
would need a non-dev release to CPAN first. So it would still be good

Quite. I rolled out a dev point release and then left it there when
no-one seemed very interested about the matter.

to hear from David if he intends to maintain Pod​::Html or not, and if
core or cpan should become the upstream. I have not compared the
core and the cpan versions to see if they already diverged significantly,
but if they did, then further patching in the core might delay an
eventual non-dev release to CPAN even more.

I'll be happy to fold in/sync any changes from blead. It's a module in
desperate need of an overhaul.

David

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From david@landgren.net

Renée Bäcker a écrit :

Jan Dubois schrieb​:

On Thu, 15 Oct 2009, Bram wrote​:

So the situation is very clear​: Tom does no longer care about the
Pod​::Html code and "any" change can happen.
Ah, excellent.

The point that still needs clarification is if Pod​::Html is considered
to be dual-lifed or not. Right now Porting/Maintainers.pl claims the
module is maintained by P5P. Of course to be properly dual-lifed it
would need a non-dev release to CPAN first. So it would still be good
to hear from David if he intends to maintain Pod​::Html or not, and if
core or cpan should become the upstream. I have not compared the
core and the cpan versions to see if they already diverged significantly,
but if they did, then further patching in the core might delay an
eventual non-dev release to CPAN even more.

When it is dual-lifed, we can browse through rt.perl.org. There are

It's dual-lifed, someone have me the whatever bit. It has a queue on
rt.cpan now (but I'll take the bugs where I find 'em).

David

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From @jandubois

On Thu, 15 Oct 2009, David Landgren wrote​:

It's dual-lifed, someone have me the whatever bit. It has a queue on
rt.cpan now (but I'll take the bugs where I find 'em).

Are you sure? RT gives me an error for this URL​:

  http​://rt.cpan.org/Public/Dist/Display.html?Name=Pod-Html

And search.cpan.org doesn't index the module either​:

  http​://search.cpan.org/search?query=pod-html&mode=all

At least the latter is probably due to only having a "developer
release" on CPAN, but I don't know why there doesn't seem to
be an RT queue for it either.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2009

From @nwc10

On Thu, Oct 15, 2009 at 11​:53​:28PM +0200, David Landgren wrote​:

I'll be happy to fold in/sync any changes from blead. It's a module in
desperate need of an overhaul.

So the master repository is somewhere-not-blead? So Porting/Maintainers.pl
needs updating? Currently it thinks that it's a core module, owned by blead,
not on CPAN anywhere.

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2009

From david@landgren.net

Nicholas Clark wrote​:

On Thu, Oct 15, 2009 at 11​:53​:28PM +0200, David Landgren wrote​:

I'll be happy to fold in/sync any changes from blead. It's a module in
desperate need of an overhaul.

So the master repository is somewhere-not-blead? So Porting/Maintainers.pl

That would be http​://svnweb.mongueurs.net/Pod-Html?lang=en

needs updating? Currently it thinks that it's a core module, owned by blead,
not on CPAN anywhere.

There's only a dev release to date. The first thing I set about doing
was writing some tests, in order to get good code coverage. That would
then allow me to begin breaking things.

Nicholas Clark

Thanks,
David

--
naked, but wearing blinding lights! were it a pretty girl, she'd be
surrounded as a flame by moths

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2009

From david@landgren.net

jesse wrote​:

From http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378328​:

pod2html does not remove temporary files before exiting​:

$ ls -a
. ..
$ pod2html /dev/null > /dev/null
$ ls -a
. .. pod2htmd.tmp pod2htmi.tmp

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

I had a look at the code again. These temporary files are in fact
caches, that allow subsequent runs of pod2html to insert cross
references to POD it already knows about. (Mind you, how it works (or
not) is a mystery to me).

Ideally, these cache files would be stored long-term in a shared
directory somewhere so that subsequent runs of pod2html could refer to
them. Afterwards, any CPAN module that contains a link e.g., SEE ALSO
L<perlipc>, could have its documentation HTMLified and linkified correctly.

In the grand scheme of things, what I really wanted to do with this
module was to be able to cross off the "make HTML install work" perltodo
item.

If you want, I could produce sync patches against blead as is, and it
could go out the door with 5.11.1

Otherwise, in the test suite I wrote, these temp files are cleaned up.
Feel free to steal them for the time being.

David

--
naked, but wearing blinding lights! were it a pretty girl, she'd be
surrounded as a flame by moths

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2009

From @nwc10

On Fri, Oct 16, 2009 at 11​:26​:27AM +0200, David Landgren wrote​:

jesse wrote​:

From http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378328​:

pod2html does not remove temporary files before exiting​:

$ ls -a
. ..
$ pod2html /dev/null > /dev/null
$ ls -a
. .. pod2htmd.tmp pod2htmi.tmp

Ideally, these cache files would be stored long-term in a shared
directory somewhere so that subsequent runs of pod2html could refer to
them. Afterwards, any CPAN module that contains a link e.g., SEE ALSO
L<perlipc>, could have its documentation HTMLified and linkified correctly.

That seems eminently sensible.

I might be jumping in on a design that already exists, but is it viable to
have a configurable cache dir, if that is configured, use it as described
above, else use File​::Temp and have that clear them away.

If you want, I could produce sync patches against blead as is, and it
could go out the door with 5.11.1

What I was thinking, which might cause problems if we do both at the same
time, is that as Pod​::Html is dual life, and core is not master, then it
should be moved in core from lib/ to cpan/Pod-Html, to show that there is
an upstream, and patches should be sent there instead of being applied
directly.

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2009

From @obra

If you want, I could produce sync patches against blead as is, and it
could go out the door with 5.11.1

If you push a new Pod​::Html dev release to CPAN, I'd happily take
patches to sync it up for 5.11.1 or just a poke to integrate it myself.

Thanks!

@p5pRT
Copy link
Author

p5pRT commented Nov 27, 2011

From @cpansprout

On Fri Oct 16 02​:25​:11 2009, david@​landgren.net wrote​:

jesse wrote​:

From http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378328​:

pod2html does not remove temporary files before exiting​:

$ ls -a
. ..
$ pod2html /dev/null > /dev/null
$ ls -a
. .. pod2htmd.tmp pod2htmi.tmp

Verified as still being an issue on blead. Is there a reason Pod​::Html
doesn't use File​::Temp?

I had a look at the code again. These temporary files are in fact
caches, that allow subsequent runs of pod2html to insert cross
references to POD it already knows about. (Mind you, how it works (or
not) is a mystery to me).

Ideally, these cache files would be stored long-term in a shared
directory somewhere so that subsequent runs of pod2html could refer to
them. Afterwards, any CPAN module that contains a link e.g., SEE ALSO
L<perlipc>, could have its documentation HTMLified and linkified
correctly.

I notice that Pod​::Html no longer produces such files as of the merge
that happened with cfe287a. Does that mean this issue is simply
resolved, or are there deeper implications that something might be
broken with regard to caches?

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 28, 2011

@cpansprout - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Nov 28, 2011
@p5pRT
Copy link
Author

p5pRT commented Nov 28, 2011

From marcgreen@WPI.EDU

I notice that Pod​::Html no longer produces such files as of the merge
that happened with cfe287a. Does that mean this issue is simply
resolved, or are there deeper implications that something might be
broken with regard to caches?

The cache feature no longer exists as of that merge, so I believe the issue can be considered "resolved".

@p5pRT
Copy link
Author

p5pRT commented Nov 28, 2011

From marcgreen@WPI.EDU

I received a message saying that my email could not be delivered. Here it is again.

__________________________

I notice that Pod​::Html no longer produces such files as of the merge
that happened with cfe287a. Does that mean this issue is simply
resolved, or are there deeper implications that something might be
broken with regard to caches?

The cache feature no longer exists as of that merge, so I believe the issue can be considered "resolved".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant