On Sun, 29 Jan 2006 17:13:40 -0800, Tyler MacDonald [EMAIL PROTECTED]
said:
Andreas J. Koenig [EMAIL PROTECTED] wrote:
FWIW, we're using dh-make-perl to create debian packages from CPAN
modules.
Andreas,
I've used this tool a few times when a CPAN module wasn't already
On Sun, 29 Jan 2006 15:05:02 -0800, Tyler MacDonald [EMAIL PROTECTED]
said:
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
Did anybody here have played with CPANPLUS::Dist::Deb?
http://search.cpan.org/dist/CPANPLUS-Dist-Deb/
Believing its documentation, it should build a valid
Adam Kennedy writes:
[Tels writes:]
if there is a problem with Module::Install, you have to update all
your dists with the new version
But if there is a problem with EU::MM or Module::Build, you have to
update every installation in the entire world with the new version.
Not
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.
So how, then, do I tell the testing system this module only works on
Unix-like filesystems on
Tels wrote:
On Saturday 28 January 2006 08:20, Tyler MacDonald wrote:
That is such an incredibly good idea. I've got plenty of bandwidth
to burn and I'm willing to set up debian.cpan.org.
Of course you must reliaze that, except for pure-perl modules and very
controlled environments, binary
Luke Closs wrote:
I'm somewhat new to the Perl community, so I don't know much history
about PPM + perl, but I think PPM is actually a pretty good tool.
The history is that Activestate was originally a Windows-only product.
Windows users generally don't have compilers, so they needed a way
On Sat, Jan 28, 2006 at 09:34:09AM -0800, Tyler MacDonald wrote:
From what I gather, CPANPLUS is a linear package building
system, whereas YACsmoke is a wrapper around that that tries to build as
many packages as is humanly (er, computerly) possible on a system, with the
side
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
Luke Closs wrote:
PPM is only really useful on Windows. It makes sense for it to bundled
with the main Windows port of perl, but not to include it otherwise.
I don't know if I buy that. Im assuming that ppm is bundled with all
of the AS
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.
So how, then, do I tell the testing
demerphq wrote:
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.
So how, then, do I tell
David Cantrell wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes
it has a platform that is compatible with the needs of the module, but
when it tries to install tests fail.
So how, then, do I tell the testing system this module only works on
David Golden wrote:
Well, the more generalized problem is how to you signal to an automated
test that you're bailing out as N/A for whatever reason? For Perl
itself, it's easy enough for the smoke test to check if the required
version of Perl is available -- and the smoke test is smart
On Jan 30, 2006, at 10:04 AM, David Cantrell wrote:
[...] for example, on OS X, HFS+ is case-preserving but case-
insensitive. UFS is case-sensitive. And FAT16 smashes case.
And to make matters even worse (better?) Apple added a case-sensitive
mode to HFS+ in 10.4. It's not widely used.
David Cantrell wrote:
David Golden wrote:
What's a clean, generic mechanism for a distribution to signal please
check this dependency and abort if it's not satisfied?
die(wrong platform, you didn't read the documentation\n)
unless(
$Config::capabilities{filesystem}{casesensitive}
* demerphq [EMAIL PROTECTED] [2006-01-30 14:50]:
Hopefully it will be something like:
$I::don't::bother::to::write::portable::code=1;
Yeah, those Win32:: modules are really unportable. It sucks.
Wink wink,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Moin,
On Monday 30 January 2006 14:59, David Golden wrote:
demerphq wrote:
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it
believes it has a platform that is compatible with the needs of the
module, but
In article
[EMAIL PROTECTED], demerphq
[EMAIL PROTECTED] wrote:
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it
In article [EMAIL PROTECTED], Adam
Kennedy [EMAIL PROTECTED] wrote:
And if there is a problem with Module::Install, you have to update all
your dists with the new version - solve one problem, create two new
ones :)
But if there is a problem with EU::MM or Module::Build, you have to
On 1/27/06, Tyler MacDonald [EMAIL PROTECTED] wrote:
Usually this clears up in about a day, but in some cases it's been 3 or 4
days now and search.cpan.org is telling me that tests have run, but
testers.cpan.org doesn't seem to know anything about them.
Sorry, I'll prod testers.cpan.org
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
demerphq wrote:
On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote:
So how, then, do I tell the testing system this module only works on
Unix-like filesystems on Unix-like OSes?
Hopefully it will be something like:
brian d foy wrote:
In article [EMAIL PROTECTED], Adam
Kennedy [EMAIL PROTECTED] wrote:
And if there is a problem with Module::Install, you have to update all
your dists with the new version - solve one problem, create two new
ones :)
But if there is a problem with EU::MM or Module::Build,
On Monday 30 January 2006 20:40, Adam Kennedy wrote:
Incremental releasing is a toolchain problem.
Having to rerelease more than one module and making every one of my users
upgrade every module that uses this tool -- not just my one or more modules
-- rather than making every one who uses the
chromatic wrote:
On Monday 30 January 2006 20:40, Adam Kennedy wrote:
Incremental releasing is a toolchain problem.
Having to rerelease more than one module and making every one of my users
upgrade every module that uses this tool -- not just my one or more modules
-- rather than making
chromatic wrote:
On Monday 30 January 2006 20:40, Adam Kennedy wrote:
Incremental releasing is a toolchain problem.
Having to rerelease more than one module and making every one of my users
upgrade every module that uses this tool -- not just my one or more modules
-- rather than making
On Monday 30 January 2006 23:15, A. Pagaltzis wrote:
* Adam Kennedy [EMAIL PROTECTED] [2006-01-31 07:50]:
There isn't really any very good way (that I can see at least)
to ensure that an end-user gets an update to EUMM/MB, just the
module packager.
So maybe that is the fundamental problem
* Adam Kennedy [EMAIL PROTECTED] [2006-01-31 07:50]:
There isn't really any very good way (that I can see at least)
to ensure that an end-user gets an update to EUMM/MB, just the
module packager.
So maybe that is the fundamental problem that should be
addressed?
Regards,
--
Aristotle Pagaltzis
* chromatic [EMAIL PROTECTED] [2006-01-31 08:20]:
Perhaps CPAN/CPANPLUS should check for updates?
Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an
equivalent?)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
27 matches
Mail list logo
