[32715] in Perl-Users-Digest
Perl-Users Digest, Issue: 3979 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 1 14:09:16 2013
Date: Mon, 1 Jul 2013 11:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 1 Jul 2013 Volume: 11 Number: 3979
Today's topics:
[OT] CGI: "Fast" vs. "classic" <oneingray@gmail.com>
Re: [OT] CGI: "Fast" vs. "classic" <rweikusat@mssgmbh.com>
a-Moose-ing CGI <oneingray@gmail.com>
Re: a-Moose-ing CGI <rweikusat@mssgmbh.com>
Re: a-Moose-ing CGI <ben@morrow.me.uk>
Re: a-Moose-ing CGI <rweikusat@mssgmbh.com>
Re: a-Moose-ing CGI <ben@morrow.me.uk>
Re: issues with POD (Seymour J.)
Re: issues with POD <oneingray@gmail.com>
Re: issues with POD <rweikusat@mssgmbh.com>
Re: issues with POD <ben@morrow.me.uk>
Re: issues with POD <hjp-usenet3@hjp.at>
Re: issues with POD <ben@morrow.me.uk>
Re: Status of Perl for OS/2? <komh@chollian.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 01 Jul 2013 17:27:25 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [OT] CGI: "Fast" vs. "classic"
Message-Id: <878v1q42de.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
[Cross-posting to news:comp.infosystems.www.servers.unix.]
[...]
>> One of the major advantages of FCGI/HTTP proxying rather than plain
>> CGI is that it is straightforward to have the webserver and the
>> application itself running under separate uids, both started
>> (ultimately) from init, without having anything setuid or running as
>> root.
> One of disadvantages of separating 'a web application' into a 'web
> server component' and 'an application server component' is that this
> means that one more permanently running daemon must be configured to
> run as an untrusted user and possibly even that it must be
> specifically told that it shouldn't bind its network sockets to the
> wildcard address (like JBoss)
It's certainly not impossible to fork a process which creates a
network socket bound to a wildcard address from a "classic" CGI
process.
Not to mention that when properly implemented, the only socket
used by the "application server" would be a "Unix domain" one.
[...]
>> This is impossible with CGI, since the application is invoked by the
>> webserver, so either it runs under the webserver's uid or the
>> webserver has to be able to switch uid.
> If 'the application is invoked from the webserver', this means it
> will - by default - run as an unprivileged user with no additional
> cost. This also includes that any access restrictions affecting this
> user will - by default - affect the application as well (with no
> additional cost).
... However, if "a bunch of applications are invoked from the
Web server," this means that all of them will use the same
unprivileged user, thus ruining the privilege separation.
And why, even a single "classic" CGI application has enough
permissions to kill () its parent -- the HTTP server. Or to
mangle its logs, screw its runtime data (if any), etc.
Naturally, it's the very kind of problem which is easy to avoid
by having the "payload" process' lineage completely separated
from that of the HTTP server.
--
FSF associate member #7257
------------------------------
Date: Mon, 01 Jul 2013 18:45:04 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] CGI: "Fast" vs. "classic"
Message-Id: <87r4fi6uov.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
[...]
Unless this moves again into a different direction, I'm going to
ignore it. I'm interested in programming problems, here, programming
problems specifically relating to Perl, and not in this kind of "who's
the most fastly rotating humming top" 'system architecture theory
wars' (this is not supposed to be offensive, I just see no value in
such a discussion).
------------------------------
Date: Sun, 30 Jun 2013 07:56:52 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: a-Moose-ing CGI
Message-Id: <87ppv43ubf.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> OTOH, I can't help thinking that it is a very strange coincidence
> that Moose is positively unusable for CGI programs, provided that
> what is reported about the time needed to compile it is correct (or -
> for that matter - for anything which isn't 'a long-running
> application' [*]) and that outspoken proponents of it want to make it
> more difficult for people to write CGI programs by removing CGI.pm
> from the Perl distribution.
CGI.pm appears to mix up CGI support and HTML generation, which
is a thing I see no good reason to do. So, I tend to advocate
in favor of replacing it with CGI::Simple whenever possible.
(My Web pages are generated with XML::LibXML::toFH (), anyway.)
Moreover, thanks to Fast CGI (and FCGI.pm), it's possible to
serve multiple HTTP requests without restarting the CGI code.
And, it may also allow for more flexible privilege separation
(than mod_suexec, anyway.)
As for Moose, I've scanned through the documentation, but didn't
quite grasp its utility as of yet.
> [*] Imagine that people actually write modularized and
> object-oriented system configuration tools ...
--
FSF associate member #7257
------------------------------
Date: Sun, 30 Jun 2013 14:05:52 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a-Moose-ing CGI
Message-Id: <87sizz695b.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
> > OTOH, I can't help thinking that it is a very strange coincidence
> > that Moose is positively unusable for CGI programs, provided that
> > what is reported about the time needed to compile it is correct (or -
> > for that matter - for anything which isn't 'a long-running
> > application' [*]) and that outspoken proponents of it want to make it
> > more difficult for people to write CGI programs by removing CGI.pm
> > from the Perl distribution.
>
> CGI.pm appears to mix up CGI support and HTML generation, which
> is a thing I see no good reason to do.
The 'good reason' would be that CGI programs usually both consume
input and produce output. While I'm not particularly fond of the HTML
generation support in CGI.pm, the basic idea of generating HTML using
a procedural interface has something going for it: In this way, it
possible to use a 'high-level interface' whose parts represent the
logical structure of a form. This makes modifications of this logical
structure much easier than when having to deal with some kind of
proto-HTML markup language with an HTML-like syntax and some typically
fairy 'dumb' (insofar programmbility goes) support for value
interpolation. 'Circumstances' forced me to get some first-hand
experiences with JSF and RichFaces and the 'template pages' generated
in this way are generally huge, repetitive angle bracket swamps. I
understand that 'the typical programmer' never uses a loop (or -
heaven forbid - a subroutine) when he can just copy'n'paste identical
code fifteen times in a row (and thus minimize the amount of work
needed for each of the slightly different fifteen individual cases)
but the result of this is an unwieldy and rigid structure which
reminds me of a frozen rubbish heap (extended by throwing more stuff
onto it and waiting for it to freeze but never modified in any other
way as this would be prohibitively expensive).
> So, I tend to advocate
> in favor of replacing it with CGI::Simple whenever possible.
> (My Web pages are generated with XML::LibXML::toFH (),
> anyway.)
I've had a look at that. A missing feature I absolutely need jumped at
me immediately: Support for accessing uploaded file data without
creating a temporary file first. Neither CGI.pm not CGI::Simple seem
to be 'maintained' in the sense that anybody bothers to deal with CPAN
bug reports, however, this here
https://rt.cpan.org/Public/Bug/Display.html?id=64160
is an absolute showstopper for me: I have to humour people with a
seriously high level of professional paranoia (yes, I do mean that) and
'open CVEs' are ratpoison in this respect. I can, of course, maintain
the code myself but I could as well just write it myself and the
result would very likely be less buggy and perform better for my use
cases.
> Moreover, thanks to Fast CGI (and FCGI.pm), it's possible to
> serve multiple HTTP requests without restarting the CGI code.
... 'we can just write a long-running application instead' ... well,
yes. I've also done that in the past, although based on mod_perl (the
mod_perl I have even behaves like its documentation says it should
because I forced it to ...). But if I can get by with the more
'UNIX(*)-style' approach of using relatively small, independent
cooperating processes, I prefer to do that. Maybe because I'm old
enough that my first impression of this world wasn't the 'designed for
Windows 98' logo but young enough to feel no haste to chase whatever
happens to be modern now because it happens to be modern now (lest I
could be ... left behind !!1) but so be it.
> And, it may also allow for more flexible privilege separation
> (than mod_suexec, anyway.)
Being able to switch UIDs on UNIX(*) means 'running with elevated
privileges' and if I don't absolutely have to use some 'huge' piece of
software for that whose innards are essentially unknown to me, I
prefer to avoid that. And this means small, setuid-0 C programs which
don't perform any function except 'uid switching', usually, to a
hard-coded persona, and only executable by the user supposed to execute
them.
------------------------------
Date: Mon, 1 Jul 2013 13:26:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a-Moose-ing CGI
Message-Id: <h598aa-3f4.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ivan Shmakov <oneingray@gmail.com> writes:
>
[FCGI]
> > And, it may also allow for more flexible privilege separation
> > (than mod_suexec, anyway.)
>
> Being able to switch UIDs on UNIX(*) means 'running with elevated
> privileges' and if I don't absolutely have to use some 'huge' piece of
> software for that whose innards are essentially unknown to me, I
> prefer to avoid that.
I'm not sure what you're saying here. One of the major advantages of
FCGI/HTTP proxying rather than plain CGI is that it is straightforward
to have the webserver and the application itself running under separate
uids, both started (ultimately) from init, without having anything
setuid or running as root. This is impossible with CGI, since the
application is invoked by the webserver, so either it runs under the
webserver's uid or the webserver has to be able to switch uid.
> And this means small, setuid-0 C programs which
> don't perform any function except 'uid switching', usually, to a
> hard-coded persona, and only executable by the user supposed to execute
> them.
I try to avoid setuid altogether. Daemons are started from /etc/rc or
managed with daemontools, and once that process tree has switched down
from root it never goes back.
Ben
------------------------------
Date: Mon, 01 Jul 2013 18:12:19 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a-Moose-ing CGI
Message-Id: <87vc4u6w7g.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ivan Shmakov <oneingray@gmail.com> writes:
>>
> [FCGI]
>> > And, it may also allow for more flexible privilege separation
>> > (than mod_suexec, anyway.)
>>
>> Being able to switch UIDs on UNIX(*) means 'running with elevated
>> privileges' and if I don't absolutely have to use some 'huge' piece of
>> software for that whose innards are essentially unknown to me, I
>> prefer to avoid that.
>
> I'm not sure what you're saying here.
In the given context, that I wouldn't want to use mod_suexec for
anything as this would necessarily imply that 'the CGI executor' (or
at least some part of it) had to run with elevated privileges by
default and consequently, that mentioning it here is somewhat out of
place.
> One of the major advantages of FCGI/HTTP proxying rather than plain
> CGI is that it is straightforward to have the webserver and the
> application itself running under separate uids, both started
> (ultimately) from init, without having anything setuid or running as
> root.
One of disadvantages of separating 'a web application' into a 'web
server component' and 'an application server component' is that this
means that one more permanently running daemon must be configured to
run as an untrusted user and possibly even that it must be
specifically told that it shouldn't bind its network sockets to the
wildcard address (like JBoss) and possibly, it will even create
listening sockets bound to the wildcard address nevertheless (like
JBoss 5). Even if said application server doesn't kindly offer its own
'attack surface' (slight misuse of the term), it is still a bunch of
more code reachable from the network.
> This is impossible with CGI, since the application is invoked by the
> webserver, so either it runs under the webserver's uid or the
> webserver has to be able to switch uid.
If 'the application is invoked from the webserver', this means it will
- by default - run as an unprivileged user with no additional
cost. This also includes that any access restrictions affecting this user
will - by default - affect the application as well (with no additional
cost).
------------------------------
Date: Mon, 1 Jul 2013 18:52:16 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a-Moose-ing CGI
Message-Id: <g7s8aa-qb6.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ivan Shmakov <oneingray@gmail.com> writes:
> >>
> > [FCGI]
> >> > And, it may also allow for more flexible privilege separation
> >> > (than mod_suexec, anyway.)
> >>
> >> Being able to switch UIDs on UNIX(*) means 'running with elevated
> >> privileges' and if I don't absolutely have to use some 'huge' piece of
> >> software for that whose innards are essentially unknown to me, I
> >> prefer to avoid that.
> >
> > I'm not sure what you're saying here.
>
> In the given context, that I wouldn't want to use mod_suexec for
> anything as this would necessarily imply that 'the CGI executor' (or
> at least some part of it) had to run with elevated privileges by
> default and consequently, that mentioning it here is somewhat out of
> place.
I see. In that case, I entirely agree. I don't like the concept of
mod_suexec either.
> > One of the major advantages of FCGI/HTTP proxying rather than plain
> > CGI is that it is straightforward to have the webserver and the
> > application itself running under separate uids, both started
> > (ultimately) from init, without having anything setuid or running as
> > root.
>
> One of disadvantages of separating 'a web application' into a 'web
> server component' and 'an application server component' is that this
> means that one more permanently running daemon must be configured to
> run as an untrusted user and possibly even that it must be
> specifically told that it shouldn't bind its network sockets to the
> wildcard address (like JBoss) and possibly, it will even create
> listening sockets bound to the wildcard address nevertheless (like
> JBoss 5). Even if said application server doesn't kindly offer its own
> 'attack surface' (slight misuse of the term), it is still a bunch of
> more code reachable from the network.
Well, I didn't say the application had to be written incompetently :).
Nevertheless, if you are obliged to run an app which is, it's much
easier to lock it down (with jails/MAC/whatever) if it's running as a
separately-managed process tree than if it's invoked ad-hoc by the
webserver.
> > This is impossible with CGI, since the application is invoked by the
> > webserver, so either it runs under the webserver's uid or the
> > webserver has to be able to switch uid.
>
> If 'the application is invoked from the webserver', this means it will
> - by default - run as an unprivileged user with no additional
> cost. This also includes that any access restrictions affecting this user
> will - by default - affect the application as well (with no additional
> cost).
I don't want my applications running as the web server user. My apps
necessarily have access to files and other resources (database sockets
and so on) which I don't want to give the web server user access to. The
web server user is 'extremely untrusted', because it's running a process
which is directly exposed to the Internet; ideally, the system as a
whole would remain entirely secure even if the webserver process was
entirely compromised. (I don't suppose I reach that ideal in practice, I
do what I can in that direction.)
Ben
------------------------------
Date: Sun, 30 Jun 2013 08:37:16 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: issues with POD
Message-Id: <51d0267c$2$fuzhry+tra$mr2ice@news.patriot.net>
In <877ghe786a.fsf@violet.siamics.net>, on 06/28/2013
at 12:04 PM, Ivan Shmakov <oneingray@gmail.com> said:
> That being said, I'm (obviously) not familiar with perldoc.
> Thus, I'm curious if there's any compelling reason for perldoc
> /not/ to support, say, DocBook (or DITA, HTML, TEI, etc.)?
Is there any compelling reason for DecBook et al to not support
perldoc? I'd be happy if the Perl community magically switched to
DocBook, but as a practical matter the cost of converting everything
would be to high. A mixture of two different documentation formats
could get very ugly very quickly.
> My point is that I know of no reason for a programmer looking
> for a new language to learn to choose Perl,
CPAN
> The other point to note is that even though I'm using Perl for
> almost decade and a half now (on and off), I still can't make
> head or tail of it at times. On the contrary, while I have put
> virtually no effort to learn Python whatsoever, I seem to
> understand the code written in it quite well.
The most arcane part of Perl is the Regex sybtax; Python and Ruby are
in the same tradition. I'd really prefer something more in the
tradition of Icon, SNOBOL and Wylbur.
> The other reason is that Perl isn't of the "one size fits all"
> type. Contrast it with Python ("one indentation fits all"),
"We hates it, precious, we hates the nasty thing." I'll take
semicolons and a prettyprinter, TYVM.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Sun, 30 Jun 2013 17:57:20 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: issues with POD
Message-Id: <87li5r4h33.fsf@violet.siamics.net>
>>>>> Shmuel (Seymour J ) Metz <spamtrap@library.lspace.org.invalid> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> said:
>> That being said, I'm (obviously) not familiar with perldoc. Thus,
>> I'm curious if there's any compelling reason for perldoc /not/ to
>> support, say, DocBook (or DITA, HTML, TEI, etc.)?
> Is there any compelling reason for DecBook et al to not support
> perldoc? I'd be happy if the Perl community magically switched to
> DocBook, but as a practical matter the cost of converting everything
> would be to high.
Yes.
> A mixture of two different documentation formats could get very ugly
> very quickly.
Why?
To note is that there already /is/ a mixture, assuming that one
uses an operating system which isn't written entirely in Perl.
So, we have pure-roff; roff generated from a variety of sources
(including both DocBook and Pod); AsciiDoc; Markdown; plain text
(mainly READMEs; in ASCII, UTF-8, and, occasionally, other
encodings); Texinfo; and what not. And all of that appears to
work reasonably well in practice.
>> My point is that I know of no reason for a programmer looking for a
>> new language to learn to choose Perl,
> CPAN
... Which I've actually mentioned (kind of.) But then, take a
look at, say, [1, 2].
... But it may be a reason worth considering. We're currently
preparing for the local SFD event, and I guess we may invest
some time in writing a dozen or so of blog entries on free
software (and digital freedom in general.) Hopefully, I'd be
able to write something reasonably decent on Perl. Naturally,
CPAN would be the first feature to mention.
[1] http://pypi.python.org/pypi
[2] http://code.google.com/p/go-wiki/wiki/Projects
>> The other point to note is that even though I'm using Perl for
>> almost decade and a half now (on and off), I still can't make head
>> or tail of it at times. On the contrary, while I have put virtually
>> no effort to learn Python whatsoever, I seem to understand the code
>> written in it quite well.
> The most arcane part of Perl is the Regex sybtax;
To me, the most arcane part of Perl is that it behaves as if it
actually /is parsed/ with a bunch of REs.
--cut: https://en.wikipedia.org/wiki/Perl --
[...] One consequence of this is that Perl is not a tidy language.
It includes many features, tolerates exceptions to its rules, and
employs heuristics to resolve syntactical ambiguities. [...]
--cut: https://en.wikipedia.org/wiki/Perl --
The "dualvar" scalars I've recently discovered also do not look
like a particularly clever concept.
> Python and Ruby are in the same tradition. I'd really prefer
> something more in the tradition of Icon, SNOBOL and Wylbur.
Could you please show some example, comparing the approaches?
>> The other reason is that Perl isn't of the "one size fits all" type.
>> Contrast it with Python ("one indentation fits all"),
> "We hates it, precious, we hates the nasty thing." I'll take
> semicolons and a prettyprinter, TYVM.
So will I.
And the same for Go, which allows for:
foo = (42 +
bar +
hello);
but not (my preference):
foo = (42
+ bar
+ hello);
(Precisely because a newline after a non-operator is taken for
an "implied semicolon".)
--
FSF associate member #7257
------------------------------
Date: Sun, 30 Jun 2013 19:44:43 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: issues with POD
Message-Id: <871u7jcuas.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>> it has been mangled by over-zealous packagers looking to save a few
>> bytes. You need to find which magic package to install to give you
>> the whole thing.
>
> Fortunately, with the error message quoted above, the packagers
> already made that a trivial thing to do.
>
> JFTR: the purpose of such splits is to avoid the installation of
> the documentation on the hosts that merely /run/ existing code,
> and aren't used for the actual development.
In order to accomplish what? According to dpkg --print-avail, the size
of perl-doc is about 6.9M. Except rare special cases, the
inconvenience of not having the documentation at hand in some 'strange
situation' by far outweighs the possible 'space saving' here except
that some people presumably feel that 'documentation' is dead weight
because they would never read it, anyway[*].
[*] Nice little anecdote about that: A former colleague of mine used
to boast that 'only newbies read documentation' ("Nur Anfaenger lesen
Dokumentation"). Once upon a time, he and my boss went to China in
order to perform some demos there for some prospective 'large
customers'. By this time, the server part of the then-product was
usually installed on SuSE Linux systems because that was what said
former colleague always used. Consequently, he went to China with a
brand new 'free SuSE CD'. Nobody ever bothered to test this new
version together with our software and since no 'newbies' where
involved here, nobody bothered to read through the release notes for
incompatible changes, either. The end result of that was that I was
woken by an "It doesn't work and we don't know what to do" phone call
around 3am, had to go the the office and read the documentation for
him in order to determine what the problem was (MySQL default date
output format changed) and to change the software to be able to deal
with that (of course, this guy still makes more money than I do ...).
[...]
> My point is that I know of no reason for a programmer looking
> for a new language to learn to choose Perl,
It is a highly useful programming language whose 'crudely implemented
Lisp subset' is fairly complete -- you'll even get run-time modifiable
symbol tables and symbols (called globs) -- with support for automatic
management of all kinds of resources and more than decent
performance. Eg, I use OO-Perl to make real-time WWW content-filtering
descisions and the latency of that is in the order of at most about a
dozebn 0.0001s --- that's something Java developers don't even dream
of (OTOH, it is presumably possible to force perl down to
JBoss/Hibernate/SEAM levels by adding enough 'CPAN frameworks' to it).
------------------------------
Date: Mon, 1 Jul 2013 13:29:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: issues with POD
Message-Id: <9a98aa-3f4.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Thu, 27 Jun 2013 22:21:29 +0100, Ben Morrow wrote:
>
> > Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>
> >> $ perldoc Pod::Man You need to install the perl-doc package to use this
> >> program.
> >
> > Your perl install is broken; it has been mangled by over-zealous
> > packagers looking to save a few bytes. You need to find which magic
> > package to install to give you the whole thing.
>
> Maybe that magic package would be perl-doc? :-)
I didn't mean just the docs; I don't know what else might have been
stripped out, and you really need all of it. I presume there is some
perl-complete package you can install which will pull in everything the
CPAN tarball would give you.
Ben
------------------------------
Date: Mon, 1 Jul 2013 17:19:08 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: issues with POD
Message-Id: <slrnkt37fc.10v.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-01 12:29, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
>> On Thu, 27 Jun 2013 22:21:29 +0100, Ben Morrow wrote:
>> > Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >> $ perldoc Pod::Man You need to install the perl-doc package to use
>> >> this program.
>> >
>> > Your perl install is broken; it has been mangled by over-zealous
>> > packagers looking to save a few bytes.
:-) Push the right button and Ben sounds like Rainer.
>> > You need to find which magic package to install to give you the
>> > whole thing.
>>
>> Maybe that magic package would be perl-doc? :-)
>
> I didn't mean just the docs; I don't know what else might have been
> stripped out, and you really need all of it. I presume there is some
> perl-complete package you can install which will pull in everything the
> CPAN tarball would give you.
Maybe, maybe not. In 10+ years of using Debian (and even more of using
Redhat, which has a similar packaging philosophy) I've never missed
having a package or meta-package which included "everything the CPAN
tarball would give me". I have a working perl installation and when a
feature is missing, it is usually straightforward to find out which
package provides it and install that. I don't care whether a module is
part of the core or not.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 1 Jul 2013 18:38:58 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: issues with POD
Message-Id: <ier8aa-qb6.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-07-01 12:29, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> >> On Thu, 27 Jun 2013 22:21:29 +0100, Ben Morrow wrote:
> >> > Quoth Ivan Shmakov <oneingray@gmail.com>:
> >> >> $ perldoc Pod::Man You need to install the perl-doc package to use
> >> >> this program.
> >> >
> >> > Your perl install is broken; it has been mangled by over-zealous
> >> > packagers looking to save a few bytes.
>
> :-) Push the right button and Ben sounds like Rainer.
Touché :).
> >> > You need to find which magic package to install to give you the
> >> > whole thing.
> >>
> >> Maybe that magic package would be perl-doc? :-)
> >
> > I didn't mean just the docs; I don't know what else might have been
> > stripped out, and you really need all of it. I presume there is some
> > perl-complete package you can install which will pull in everything the
> > CPAN tarball would give you.
>
> Maybe, maybe not. In 10+ years of using Debian (and even more of using
> Redhat, which has a similar packaging philosophy) I've never missed
> having a package or meta-package which included "everything the CPAN
> tarball would give me". I have a working perl installation and when a
> feature is missing, it is usually straightforward to find out which
> package provides it and install that. I don't care whether a module is
> part of the core or not.
That's certainly a sensible attitude if you rely on OS-packaged perl
modules: one would assume that they pull in bits of the 'core' package
as needed, and that they have been tested with whatever bits of code
they do actually pull in. However, once you start installing modules
directly from CPAN (which I don't recommend with an OS-installed perl in
any case), or developing your own, you start to find that Perl
developers assume 'perl vX means you have module Y in core', or 'header
H', or 'Unicode data file U', and these assumptions no longer
necessarily hold.
I am speaking from the background of rather a lot of bug reports which
end up like this
'...I don't have ___.'
'You ought to, it's in the core.'
'...Oh, right, my OS package doesn't include that...'
not to mention the 'but perldoc doesn't work' people we get here from
time to time.
Ben
------------------------------
Date: Mon, 01 Jul 2013 22:45:13 +0900
From: KO Myung-Hun <komh@chollian.net>
To: Paul Smedley <paul@smedley.id.au>
Subject: Re: Status of Perl for OS/2?
Message-Id: <51D187E9.7080204@chollian.net>
Paul Smedley wrote:
> On 18/06/13 21:07, KO Myung-Hun wrote:
>> Hi/2.
>>
>> Paul Smedley wrote:
>>> Hi Shmuel,
>>>
>>> On 18/06/13 02:14, Shmuel (Seymour J.) Metz wrote:
>>>> The perldelta for 5.18 suggests that if nobody is actively working on
>>>> Perl for OS/2 then the Perl developers may drop the OS/2 related code.
>>>> I'm currently using Perl 5.10; Perl 5.14 had path rewriter issues and
>>>> I'm not aware of a more recent build for OS/2. Is anybody in the OS/2
>>>> community working on Perl 5.16 or 5.18, and, if so, have they made
>>>> themselves known to the Perl developers?
>>>
>>> http://smedley.id.au/tmp/perl-5.16.3-os2-20130519.zip
>>>
>>
>> This version has corrupted os2ish.h and os2thread.h. They seems to be
>> just a symbolic link.
>>
> I can zip them up for you if you need them - they are probably unchanged
> from Perl 5.14 or 5.10 tho
It's not just for me. Anyone who tries to compile CPAN modules, will
fails because of this.
It would be better to distribute the fixed build.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.24 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3979
***************************************
