Re: How do you manage Perl modules?
On Mon, Feb 09, 2004 at 05:06:54PM -0500, Kris Deugau wrote: Dan MacNeil wrote: For you a (maybe painful) alternative to going to unstable is to discard your older Bayes and automatic whitelist files. *shudder* And suffer a ~20% (or more) decrease in spam filter efficiency as seen by the people paying for the service? No thanks. :/ There's about a year's worth of autolearned ham in that db, and I don't have any convenient way to relearn most of that. [snip] Should have replied to one of your earlier messages, but I've deleted them... .pag and .dir are not Berkeley DB 1, they're from dbm (or ndbm or something.) You could write a perl/python script to convert from the dbm files to bdb4 (or whatever you like.) -- Michael Wood [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Michael Wood wrote: Should have replied to one of your earlier messages, but I've deleted them... .pag and .dir are not Berkeley DB 1, they're from dbm (or ndbm or something.) In other words, not DB_File. I don't recall the reasoning exactly, but SA as of v2.6x REQUIRES DB_File vs any of the other hash-file types for the Bayes db. Anything else requires manual hacking of the SA code. :( You could write a perl/python script to convert from the dbm files to bdb4 (or whatever you like.) If I understood the hash structure used... Anyway, I've found the information I needed to fix that particular issue; so far as I can tell now the rest of the problems are just simple misconfiguration issues. g (Or not-yet-configured issues.) -kgd -- Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown
Re: How do you manage Perl modules?
Angus D Madden wrote:
Assuming you have a working cpan cofniguration, you can use
dh-make-perl.
dh-make-perl --cpan module
Ah! Excellent. (Actually, you need to do
dh-make-perl --build --cpan {module}
to get a .deb out of it.)
I have used this before and it just worked. ymmv.
Looks good; that's one less problem to deal with... All I have to do
is make sure to not blindly upgrade the core Perl package. :/
-kgd
--
Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken.
- Unknown
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Dan MacNeil wrote: For you a (maybe painful) alternative to going to unstable is to discard your older Bayes and automatic whitelist files. *shudder* And suffer a ~20% (or more) decrease in spam filter efficiency as seen by the people paying for the service? No thanks. :/ There's about a year's worth of autolearned ham in that db, and I don't have any convenient way to relearn most of that. btw, the first time you ran sa-learn did you get an error? Never got that far; I'm still making sure the new box is set up and working correctly (ie, the same as the current RedHat box). For testing, I've just been feeding some test messages through the system and seeing what comes out, as well as running # spamassassin -D --lint 21 |more to see what might be going toes-up. something like like: whatsits_foo.a not in @INC --needed for Digest::SHA1 I tried to make the problem go away with apt-get but got something like: blah is already the current version I succeeded in making the problem go away w/ /usr/bin/perl -MCPAN -e install Digest::SHA1 Hmm.. Just checked on this, and I don't get any errors about Digest::SHA1. -kgd -- Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Angus D Madden wrote:
Assuming you have a working cpan cofniguration, you can use
dh-make-perl.
dh-make-perl --cpan module
Ah! Excellent. (Actually, you need to do
dh-make-perl --build --cpan {module}
to get a .deb out of it.)
I have used this before and it just worked. ymmv.
Looks good; that's one less problem to deal with... All I have to do
is make sure to not blindly upgrade the core Perl package. :/
-kgd
--
Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken.
- Unknown
Re: How do you manage Perl modules?
Dan MacNeil wrote: For you a (maybe painful) alternative to going to unstable is to discard your older Bayes and automatic whitelist files. *shudder* And suffer a ~20% (or more) decrease in spam filter efficiency as seen by the people paying for the service? No thanks. :/ There's about a year's worth of autolearned ham in that db, and I don't have any convenient way to relearn most of that. btw, the first time you ran sa-learn did you get an error? Never got that far; I'm still making sure the new box is set up and working correctly (ie, the same as the current RedHat box). For testing, I've just been feeding some test messages through the system and seeing what comes out, as well as running # spamassassin -D --lint 21 |more to see what might be going toes-up. something like like: whatsits_foo.a not in @INC --needed for Digest::SHA1 I tried to make the problem go away with apt-get but got something like: blah is already the current version I succeeded in making the problem go away w/ /usr/bin/perl -MCPAN -e install Digest::SHA1 Hmm.. Just checked on this, and I don't get any errors about Digest::SHA1. -kgd -- Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown
Re: How do you manage Perl modules?
I'm in similar situation, last night I installed spamassassin razor from backports.org. It seems to be working ok Fortunately for me, I don't have to worry about being forward compatible with an existing Bayes db. For you a (maybe painful) alternative to going to unstable is to discard your older Bayes and automatic whitelist files. Another alternative is to dump at least your whitelist to text, and then script an import btw, the first time you ran sa-learn did you get an error? something like like: whatsits_foo.a not in @INC --needed for Digest::SHA1 I tried to make the problem go away with apt-get but got something like: blah is already the current version I succeeded in making the problem go away w/ /usr/bin/perl -MCPAN -e install Digest::SHA1 # On Sun, 8 Feb 2004, Craig Sanders wrote: On Fri, Feb 06, 2004 at 05:41:18PM -0500, Kris Deugau wrote: However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. sounds like you've run into a reason to upgrade to unstable. you have three choices: 1. backport perl 5.8.x and libdb4 and all associated modules and other packages. 2. try to find a backports archive where someone else has done the same. 3. point sources.list at unstable and either 'apt-get install' perl and other packages, or 'apt-get dist-upgrade'. choice 1 is a lot of work. choice 2 doesn't really offer any benefits over just upgrading to 'unstable', or upgrading certain packages to their 'unstable' versions. choice 3 will result in the least problems, and will be better tested - there are far more people using unstable than there are using backports of perl. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules dh-make-perl can fetch a package from CPAN and produce a working package that is good enough for local use (but not polished enough to upload to debian for re-distribution). (or even just recompile the stable version against different libs). this is always an option. it's called 'back-porting'. download the debianised source from unstable (along with any build dependancies) and build it. I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. really, upgrading to 'unstable' will be the least-hassle option. 'unstable' means that the entire system is in flux, that it changes constantly. it does not mean that the packages in it are unreliable. craig ps: i've been running ALL of my production servers on 'unstable' since 1995. i upgrade them semi-regularly. no major problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
I'm in similar situation, last night I installed spamassassin razor from backports.org. It seems to be working ok Fortunately for me, I don't have to worry about being forward compatible with an existing Bayes db. For you a (maybe painful) alternative to going to unstable is to discard your older Bayes and automatic whitelist files. Another alternative is to dump at least your whitelist to text, and then script an import btw, the first time you ran sa-learn did you get an error? something like like: whatsits_foo.a not in @INC --needed for Digest::SHA1 I tried to make the problem go away with apt-get but got something like: blah is already the current version I succeeded in making the problem go away w/ /usr/bin/perl -MCPAN -e install Digest::SHA1 # On Sun, 8 Feb 2004, Craig Sanders wrote: On Fri, Feb 06, 2004 at 05:41:18PM -0500, Kris Deugau wrote: However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. sounds like you've run into a reason to upgrade to unstable. you have three choices: 1. backport perl 5.8.x and libdb4 and all associated modules and other packages. 2. try to find a backports archive where someone else has done the same. 3. point sources.list at unstable and either 'apt-get install' perl and other packages, or 'apt-get dist-upgrade'. choice 1 is a lot of work. choice 2 doesn't really offer any benefits over just upgrading to 'unstable', or upgrading certain packages to their 'unstable' versions. choice 3 will result in the least problems, and will be better tested - there are far more people using unstable than there are using backports of perl. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules dh-make-perl can fetch a package from CPAN and produce a working package that is good enough for local use (but not polished enough to upload to debian for re-distribution). (or even just recompile the stable version against different libs). this is always an option. it's called 'back-porting'. download the debianised source from unstable (along with any build dependancies) and build it. I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. really, upgrading to 'unstable' will be the least-hassle option. 'unstable' means that the entire system is in flux, that it changes constantly. it does not mean that the packages in it are unreliable. craig ps: i've been running ALL of my production servers on 'unstable' since 1995. i upgrade them semi-regularly. no major problems.
Re: How do you manage Perl modules?
Lucas Albers wrote: I use mimedefang testing, spamaassassing unstable, and kernel 2.4.23, on my production external mx server. Everything else is stable. The only externally exposed service, sendmail is stable. I tried unstable sendmail, but TLS didn't work. And I would not have timelly updates. (I was trying to resolve milter sock issues.) Works great, using perl 5.8 instaed of 5.6.1 is a much better choice for mimedefang. Use clamdscan instead of clamscan, I got the clamd from the clam site, in deb format. Clamdscan is approximatelly 200 times faster then running clamscan. The Debian clamav packages were mostly unmaintained the last 5 months, but the maintainer changed now. There will be new packages this week. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
On Fri, Feb 06, 2004 at 05:41:18PM -0500, Kris Deugau wrote: However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. sounds like you've run into a reason to upgrade to unstable. you have three choices: 1. backport perl 5.8.x and libdb4 and all associated modules and other packages. 2. try to find a backports archive where someone else has done the same. 3. point sources.list at unstable and either 'apt-get install' perl and other packages, or 'apt-get dist-upgrade'. choice 1 is a lot of work. choice 2 doesn't really offer any benefits over just upgrading to 'unstable', or upgrading certain packages to their 'unstable' versions. choice 3 will result in the least problems, and will be better tested - there are far more people using unstable than there are using backports of perl. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules dh-make-perl can fetch a package from CPAN and produce a working package that is good enough for local use (but not polished enough to upload to debian for re-distribution). (or even just recompile the stable version against different libs). this is always an option. it's called 'back-porting'. download the debianised source from unstable (along with any build dependancies) and build it. I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. really, upgrading to 'unstable' will be the least-hassle option. 'unstable' means that the entire system is in flux, that it changes constantly. it does not mean that the packages in it are unreliable. craig ps: i've been running ALL of my production servers on 'unstable' since 1995. i upgrade them semi-regularly. no major problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Lucas Albers wrote: I use mimedefang testing, spamaassassing unstable, and kernel 2.4.23, on my production external mx server. Everything else is stable. The only externally exposed service, sendmail is stable. I tried unstable sendmail, but TLS didn't work. And I would not have timelly updates. (I was trying to resolve milter sock issues.) Works great, using perl 5.8 instaed of 5.6.1 is a much better choice for mimedefang. Use clamdscan instead of clamscan, I got the clamd from the clam site, in deb format. Clamdscan is approximatelly 200 times faster then running clamscan. The Debian clamav packages were mostly unmaintained the last 5 months, but the maintainer changed now. There will be new packages this week. Thomas
Re: How do you manage Perl modules?
On Fri, Feb 06, 2004 at 05:41:18PM -0500, Kris Deugau wrote: However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. sounds like you've run into a reason to upgrade to unstable. you have three choices: 1. backport perl 5.8.x and libdb4 and all associated modules and other packages. 2. try to find a backports archive where someone else has done the same. 3. point sources.list at unstable and either 'apt-get install' perl and other packages, or 'apt-get dist-upgrade'. choice 1 is a lot of work. choice 2 doesn't really offer any benefits over just upgrading to 'unstable', or upgrading certain packages to their 'unstable' versions. choice 3 will result in the least problems, and will be better tested - there are far more people using unstable than there are using backports of perl. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules dh-make-perl can fetch a package from CPAN and produce a working package that is good enough for local use (but not polished enough to upload to debian for re-distribution). (or even just recompile the stable version against different libs). this is always an option. it's called 'back-porting'. download the debianised source from unstable (along with any build dependancies) and build it. I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. really, upgrading to 'unstable' will be the least-hassle option. 'unstable' means that the entire system is in flux, that it changes constantly. it does not mean that the packages in it are unreliable. craig ps: i've been running ALL of my production servers on 'unstable' since 1995. i upgrade them semi-regularly. no major problems.
How do you manage Perl modules?
I'm currently working on replacing a few RedHat 7.3 boxen with Debian systems- Debian primarily because it's what head office is using. Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. I've since managed to reasonably quickly and cleanly backport MIMEDefang from testing- with a few tweaks I consider NECESSARY- compile options, so post-install tweaking isn't really an option. :/ However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. -kgd -- Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
G'day, Kris Deugau wrote: [...] Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. [...] However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. [...] You have hit the big problem with stable; some packages are highly depended on by the whole distro (libc, perl, etc). Once these get out of date, you pretty much have to backport the whole distro. The eternal dilema between current and stable; do you have lots of regualar little upgrade headaches, or have very rare big nasty ones, with your system getting further and further out of date as you put off the pain. For me stable is too stable, unstable is too unstable, and testing is a nice compromise. The reality is software evolves, and your systems are going to have to evolve with it. Testing's automated all dependencies met + 2 weeks without bugs criteria is a pretty close match to my idea of an ideal distro. The worst thing missing is supporting and fast-tracking security updates. The other thing is packages that upgrade at a faster than 2 week interval... they never make it into testing (AFAIK). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( If you live in backport land, you will need a system you can build your own backports on. I don't believe you can get away without it. I suggest a seperate devel server, that can double as a before deployment testing box. Donovan Baardahttp://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Kris Deugau, Fri, Feb 06, 2004 at 05:41:18PM -0500: Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Assuming you have a working cpan cofniguration, you can use dh-make-perl. dh-make-perl --cpan module I have used this before and it just worked. ymmv. g pgp0.pgp Description: PGP signature
Re: How do you manage Perl modules?
Angus D Madden said: Assuming you have a working cpan cofniguration, you can use dh-make-perl. dh-make-perl --cpan module I have used this before and it just worked. ymmv. I use mimedefang testing, spamaassassing unstable, and kernel 2.4.23, on my production external mx server. Everything else is stable. The only externally exposed service, sendmail is stable. I tried unstable sendmail, but TLS didn't work. And I would not have timelly updates. (I was trying to resolve milter sock issues.) Works great, using perl 5.8 instaed of 5.6.1 is a much better choice for mimedefang. Use clamdscan instead of clamscan, I got the clamd from the clam site, in deb format. Clamdscan is approximatelly 200 times faster then running clamscan. You also need to hack the mimedefang restart script, so it puts a 3 second delay in a restart, otherwise the multiplexor will generate a socket error on the restart. I've spent literally hundreds of hours messing around with mimedefang on redhat/ and less amount of time with debian since then. You also want to run a swatch script to watch for milter errors, so it can restart the process when it pukes. I saw this approximatelly every 60-70 days on some boxes. If you use the embedded multiplexor for mimedefang you MUST use perl 5.8. I backported mimedefang from testing to stable, and it did not require any change in the debian file. I just had to recompile the src on a woody box. -- --Luke CS Sysadmin, Montana State University-Bozeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How do you manage Perl modules?
I'm currently working on replacing a few RedHat 7.3 boxen with Debian systems- Debian primarily because it's what head office is using. Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. I've since managed to reasonably quickly and cleanly backport MIMEDefang from testing- with a few tweaks I consider NECESSARY- compile options, so post-install tweaking isn't really an option. :/ However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. -kgd -- Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown
Re: How do you manage Perl modules?
G'day, Kris Deugau wrote: [...] Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. [...] However, I've just discovered that there's also a bad version mismatch between the default libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. [...] You have hit the big problem with stable; some packages are highly depended on by the whole distro (libc, perl, etc). Once these get out of date, you pretty much have to backport the whole distro. The eternal dilema between current and stable; do you have lots of regualar little upgrade headaches, or have very rare big nasty ones, with your system getting further and further out of date as you put off the pain. For me stable is too stable, unstable is too unstable, and testing is a nice compromise. The reality is software evolves, and your systems are going to have to evolve with it. Testing's automated all dependencies met + 2 weeks without bugs criteria is a pretty close match to my idea of an ideal distro. The worst thing missing is supporting and fast-tracking security updates. The other thing is packages that upgrade at a faster than 2 week interval... they never make it into testing (AFAIK). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( If you live in backport land, you will need a system you can build your own backports on. I don't believe you can get away without it. I suggest a seperate devel server, that can double as a before deployment testing box. Donovan Baardahttp://minkirri.apana.org.au/~abo/
Re: How do you manage Perl modules?
Kris Deugau, Fri, Feb 06, 2004 at 05:41:18PM -0500: Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Assuming you have a working cpan cofniguration, you can use dh-make-perl. dh-make-perl --cpan module I have used this before and it just worked. ymmv. g pgpjncdqqQaKp.pgp Description: PGP signature
Re: How do you manage Perl modules?
Angus D Madden said: Assuming you have a working cpan cofniguration, you can use dh-make-perl. dh-make-perl --cpan module I have used this before and it just worked. ymmv. I use mimedefang testing, spamaassassing unstable, and kernel 2.4.23, on my production external mx server. Everything else is stable. The only externally exposed service, sendmail is stable. I tried unstable sendmail, but TLS didn't work. And I would not have timelly updates. (I was trying to resolve milter sock issues.) Works great, using perl 5.8 instaed of 5.6.1 is a much better choice for mimedefang. Use clamdscan instead of clamscan, I got the clamd from the clam site, in deb format. Clamdscan is approximatelly 200 times faster then running clamscan. You also need to hack the mimedefang restart script, so it puts a 3 second delay in a restart, otherwise the multiplexor will generate a socket error on the restart. I've spent literally hundreds of hours messing around with mimedefang on redhat/ and less amount of time with debian since then. You also want to run a swatch script to watch for milter errors, so it can restart the process when it pukes. I saw this approximatelly every 60-70 days on some boxes. If you use the embedded multiplexor for mimedefang you MUST use perl 5.8. I backported mimedefang from testing to stable, and it did not require any change in the debian file. I just had to recompile the src on a woody box
