[suggest] Perl module update request list

[David Steinbrunner]

Hello All,

I would appreciate it if we could get the following cpan modules updated:

SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception

These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
but the following red hat controlled modules are outdated and prevent that:

File-Path
Test-Builder
Test-More

Thanks,

--
David Steinbrunner

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

I will have a go at it. I made a ticket
(http://trac.rpmrepo.org/trac/RPMRepo/ticket/6) for that so I don't
forget it ;)

Chris

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

Hm there is a problem with namespace::clean. It needs Package::Stash
wich won't build with ExtUtils::MakeMaker from base:

ExtUtils::MakeMaker version 6.31 required--this is only version 6.30 at
Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.


I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

Chris

[Yury V. Zaytsev]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

[R P Herrold]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

But which one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newer Version in the vendorlib dir will just not
do.

The answer cannot be mandated by the packaging system, and
rather, varies, depending on the perl module @INC contents, as
well as with any possible more specifically coded loader logic
in the script using such

I placed a spec file providing local over-rides at:
http://gallery.herrold.com/perl-ExtUtils-MakeMaker.spec

which rrdtool and perl-Authen-SASL seemed to accept

-- Russ herrold

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but never as a real requirement. Then the package belongs in the
buildtools repository (together with the newer bison and flex).

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement, but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...

A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering macros !

If we plan to replace other modules from the perl package, I would propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).

Still need a good name for that though...

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement, but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...

A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering macros !

If we plan to replace other modules from the perl package, I would propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).

Still need a good name for that though...

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement, but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...

A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering macros !

If we plan to replace other modules from the perl package, I would propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).

Still need a good name for that though...

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement, but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...

A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering macros !

If we plan to replace other modules from the perl package, I would propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).

Still need a good name for that though...

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement, but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...

A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering macros !

If we plan to replace other modules from the perl package, I would propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).

Still need a good name for that though...

[R P Herrold]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

But which one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newer Version in the vendorlib dir will just not
do.

The answer cannot be mandated by the packaging system, and
rather, varies, depending on the perl module @INC contents, as
well as with any possible more specifically coded loader logic
in the script using such

I placed a spec file providing local over-rides at:
http://gallery.herrold.com/perl-ExtUtils-MakeMaker.spec

which rrdtool and perl-Authen-SASL seemed to accept

-- Russ herrold

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but never as a real requirement. Then the package belongs in the
buildtools repository (together with the newer bison and flex).

[R P Herrold]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

But which one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newer Version in the vendorlib dir will just not
do.

The answer cannot be mandated by the packaging system, and
rather, varies, depending on the perl module @INC contents, as
well as with any possible more specifically coded loader logic
in the script using such

I placed a spec file providing local over-rides at:
http://gallery.herrold.com/perl-ExtUtils-MakeMaker.spec

which rrdtool and perl-Authen-SASL seemed to accept

-- Russ herrold

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but never as a real requirement. Then the package belongs in the
buildtools repository (together with the newer bison and flex).

[R P Herrold]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

But which one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newer Version in the vendorlib dir will just not
do.

The answer cannot be mandated by the packaging system, and
rather, varies, depending on the perl module @INC contents, as
well as with any possible more specifically coded loader logic
in the script using such

I placed a spec file providing local over-rides at:
http://gallery.herrold.com/perl-ExtUtils-MakeMaker.spec

which rrdtool and perl-Authen-SASL seemed to accept

-- Russ herrold

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but never as a real requirement. Then the package belongs in the
buildtools repository (together with the newer bison and flex).

[R P Herrold]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

But which one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newer Version in the vendorlib dir will just not
do.

The answer cannot be mandated by the packaging system, and
rather, varies, depending on the perl module @INC contents, as
well as with any possible more specifically coded loader logic
in the script using such

I placed a spec file providing local over-rides at:
http://gallery.herrold.com/perl-ExtUtils-MakeMaker.spec

which rrdtool and perl-Authen-SASL seemed to accept

-- Russ herrold

[Dag Wieers]

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but never as a real requirement. Then the package belongs in the
buildtools repository (together with the newer bison and flex).

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

[Yury V. Zaytsev]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

[Yury V. Zaytsev]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

[Yury V. Zaytsev]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

[Yury V. Zaytsev]

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

If it backwards compatible why not? Just tag it as such...

[David Steinbrunner]

Hello All,

I would appreciate it if we could get the following cpan modules updated:

SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception

These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
but the following red hat controlled modules are outdated and prevent that:

File-Path
Test-Builder
Test-More

Thanks,

--
David Steinbrunner

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

I will have a go at it. I made a ticket
(http://trac.rpmrepo.org/trac/RPMRepo/ticket/6) for that so I don't
forget it ;)

Chris

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

Hm there is a problem with namespace::clean. It needs Package::Stash
wich won't build with ExtUtils::MakeMaker from base:

ExtUtils::MakeMaker version 6.31 required--this is only version 6.30 at
Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.


I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

Chris

[David Steinbrunner]

Hello All,

I would appreciate it if we could get the following cpan modules updated:

SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception

These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
but the following red hat controlled modules are outdated and prevent that:

File-Path
Test-Builder
Test-More

Thanks,

--
David Steinbrunner

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

I will have a go at it. I made a ticket
(http://trac.rpmrepo.org/trac/RPMRepo/ticket/6) for that so I don't
forget it ;)

Chris

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

Hm there is a problem with namespace::clean. It needs Package::Stash
wich won't build with ExtUtils::MakeMaker from base:

ExtUtils::MakeMaker version 6.31 required--this is only version 6.30 at
Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.


I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

Chris

[David Steinbrunner]

Hello All,

I would appreciate it if we could get the following cpan modules updated:

SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception

These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
but the following red hat controlled modules are outdated and prevent that:

File-Path
Test-Builder
Test-More

Thanks,

--
David Steinbrunner

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

I will have a go at it. I made a ticket
(http://trac.rpmrepo.org/trac/RPMRepo/ticket/6) for that so I don't
forget it ;)

Chris

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

Hm there is a problem with namespace::clean. It needs Package::Stash
wich won't build with ExtUtils::MakeMaker from base:

ExtUtils::MakeMaker version 6.31 required--this is only version 6.30 at
Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.


I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

Chris

[David Steinbrunner]

Hello All,

I would appreciate it if we could get the following cpan modules updated:

SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception

These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
but the following red hat controlled modules are outdated and prevent that:

File-Path
Test-Builder
Test-More

Thanks,

--
David Steinbrunner

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

I will have a go at it. I made a ticket
(http://trac.rpmrepo.org/trac/RPMRepo/ticket/6) for that so I don't
forget it ;)

Chris

[Christoph Maser]

Post by David Steinbrunner
Hello All,
SQL-Translator
Math-Base36
namespace-clean
Class-Accessor-Grouped
Config-Any
Variable-Magic
SQL-Abstract
Test-Exception
These are all associated to the current or development release of
DBIx::Class. Of course, I could just ask for the an update to DBIx::Class
File-Path
Test-Builder
Test-More
Thanks,
--
David Steinbrunner

Hm there is a problem with namespace::clean. It needs Package::Stash
wich won't build with ExtUtils::MakeMaker from base:

ExtUtils::MakeMaker version 6.31 required--this is only version 6.30 at
Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.


I wonder if we can have a new version of ExtUtils::MakeMaker in the
buildtools repo?

Chris

[David Steinbrunner]

Post by Dag Wieers
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Is "overrides" to harsh of a word?

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Is "overrides" to harsh of a word?

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Is "overrides" to harsh of a word?

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Is "overrides" to harsh of a word?

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Is "overrides" to harsh of a word?

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers

Post by Dag Wieers

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in

the

Post by Yury V. Zaytsev

Post by Christoph Maser
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...
A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering
macros !
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Thanks,

--
David Steinbrunner

[David Steinbrunner]

Post by David Steinbrunner
Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Come to think of it, a better question is, can we get a package of
DBIx::Class now?!

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers

Post by Dag Wieers

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in

the

Post by Yury V. Zaytsev

Post by Christoph Maser
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...
A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering
macros !
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Thanks,

--
David Steinbrunner

[David Steinbrunner]

Post by David Steinbrunner
Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Come to think of it, a better question is, can we get a package of
DBIx::Class now?!

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers

Post by Dag Wieers

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in

the

Post by Yury V. Zaytsev

Post by Christoph Maser
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...
A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering
macros !
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Thanks,

--
David Steinbrunner

[David Steinbrunner]

Post by David Steinbrunner
Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Come to think of it, a better question is, can we get a package of
DBIx::Class now?!

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers

Post by Dag Wieers

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in

the

Post by Yury V. Zaytsev

Post by Christoph Maser
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...
A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering
macros !
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Thanks,

--
David Steinbrunner

[David Steinbrunner]

Post by David Steinbrunner
Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Come to think of it, a better question is, can we get a package of
DBIx::Class now?!

--
David Steinbrunner

[David Steinbrunner]

Post by Dag Wieers

Post by Dag Wieers

Post by Christoph Maser

Post by Yury V. Zaytsev

Post by Christoph Maser
I wonder if we can have a new version of ExtUtils::MakeMaker in

the

Post by Yury V. Zaytsev

Post by Christoph Maser
buildtools repo?

If it backwards compatible why not? Just tag it as such...

But wich one will be used?. ExtUtils::MakeMaker in in the perl base
package, so I guess a newe Version in the vendorlib dir will just not
do.

If this is the typical: we need the package only as a BuildRequirement,
but
never as a real requirement. Then the package belongs in the buildtools
repository (together with the newer bison and flex).

Replying to the wrong message, again...
A newer version in the vendorlib should work for RHEL5. The only problem
are the man-pages, which we can filter out with our fancy filtering
macros !
If we plan to replace other modules from the perl package, I would
propose
we put them in the future 'extras' repositories where all packages will
house that replace base (or depend on stuff that replace base).
Still need a good name for that though...

Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Thanks,

--
David Steinbrunner

[David Steinbrunner]

Post by David Steinbrunner
Now that extras and other build changes are in in place is the latest
namespace::clean capable of being packaged?

Come to think of it, a better question is, can we get a package of
DBIx::Class now?!

--
David Steinbrunner