[ic] Threaded Perl

Philip S. Hempel interchange-users@icdevgroup.org
Wed Jul 2 18:59:00 EDT 2003


On Wed, 2003-07-02 at 16:48, cfm@maine.com wrote:
> On Wed, Jul 02, 2003 at 04:04:34PM -0400, Philip S. Hempel wrote:
> > On Wed, 2003-07-02 at 11:56, Stefan Hornburg wrote:
> > 
> > <snip>
> > > > 
> > > > I am trying to find if there could be a way that the Perl maintainer for
> > > > Debian would be willing to create at a build with no threads as a
> > > > standard in addition to the threaded version. Hopefully he may go for
> > > > it.
> > > 
> > > Yes, please do this. And report back any results.
> > > 
> > 
> > Bug#199718 is the Debian bug I have put in today.
> > 
> > I hope others who use Debian and IC are willing to do the same. If
> > anyone kkonws of other apps that are affected by the threaded perl in
> > Debian please those of you using Debian please put in a bug report as
> > well.
> 
> 
> It is not that hard to build the debian src package.  It might be a 
> quicker fix to make a small *.deb repository for IC rather than to try
> to get a different version of perl into debian.
> 

I have this done now. 
I don't think that this is really a different version since version
5.005 of perl Debian had a threaded perl as a standard. I think all I am
asking of the maintainer is to just reverse the role and add a
non-threaded alternative to his builds.

> I'd also suggest that if you are not comfortable with above, you are
> asking for a world of hurt trying to maintain a non-standard perl
> in the middle of a packaged system.

> FWIW, minivend 4.03 runs just fine with debian's stock threaded perl.  :-)
> 

I have at present built a un-threaded Debian perl and am in the process
of cleaning it up to have one of the IC Dev's to put up. 

Having to do this for not just IC but many other apps I have found to
have problems since upgrading to perl 5.8 and threads.

I use a distribution for the reason that a distribution exists, to ease
package management and my time. 

I do not get paid for the work on our web store.  This adds to the other
reasons for wanting spend added time to deal with maintaining something
that can be easily fixed.

Perl is an integral part of an OS and I myself do not want to have keep
it up when fixes are created.

<rant>
Debian as a distribution is meant for us who use and want a system that
is stable and easy to configure. I have been using the "unstable"
version of Debian for at least 7 years now and this is first time I have
seen someone choose to take a core application that is used by Debian
itself and not fully test the implications of doing so.

I think there might be a possibility that the maintainer may mot know of
all the things that perl has effected. Because the subtle issues that
occur with the applications bugs often get placed against the
application when in fact the threaded perl is the fault.

Someone may state that if the application does not work under threaded
prel that is the apps fault, but I believe it is the other way around. 

If the addition to any standard environment produces a problem, yes it
could show how the application may have faults, but in the absence of
the addition does not, in my experience usually the addition is faulty.

</rant>

I have built my own perl from source debs and guess what, it is a pain
to do, just take building gd perl and mysql dbd, you have dependencies
that require more work than I care to do on a regular bases. 

I also want Debian to be able to properly support IC. The Debian
maintainer (Racke), will be getting many bug reports soon that people
will think is IC fault and in fact are due to Debian's threaded perl.

Red Hat is in the same boat but I have not used and do not know how open
they listen to there users. I do know that many Debian developers do.


If Debian admits to the issues with using the threaded perl many of the
other distributions may notice and follow suit (I would hope). 


Thanks again. 

-- 
Philip S. Hempel

Give a man a fish and he will feed himself for a day.
Teach a man to fish and he will feed himself for a lifetime.

http://linuxhardcore.com/




More information about the interchange-users mailing list