> ActivePerl binaries (ppm packages) will not be usable on the 64int
> architecture Strawberry Perl - unless, of course, ActiveState also start
> providing packages for the 64int architecture. (I've no idea what
> ActiveState are planning to do in this regard.)
> I doubt that many Strawberry users (if any) would be affected by this,
> and I don't regard it as a stopper.
On the other hand ActiveState ppm repositories use newer ppm format than
ppm utility included in strawberry perl is able to handle. So it is not
even today easily possible to install ppm from ActiveState repo into
Oh yes ... I think I recently discovered that there's quite a few hoops to
jump through if you want to 'ppm install' from AS repo to Strawberry Perl.
(Although I build a few ppm packages, I rarely actually use ppm - and I keep
losing track of the capabilities of this utility.)
> (Will 32int Strawberry builds still be available for anyone who wants
> one ?)
No, my idea is just one and only one 32bit strawberry perl 5.18.x with
Good - that keeps it nice and simple.
> One other thing to consider with 5.18 Strawberry is whether it should be
> COW-enabled or not.
> Until recently, the p5p plan was to make 5.18 COW-enabled, but that has
> now been postponed to 5.20 (which will definitely be COW-enabled).
> As the plan currently stands, 5.18 will build as COW-disabled by
> default - but there's an option to build it COW-enabled (which p5p are
> encouraging module authors to use - mainly to have them avoid rude
> shocks when 5.20 does come along).
As for COW I am gonna follow perl core default behaviour.
I've no problems with that. I intend to have both COW-enabled and
COW-disabled builds of 5.18.0, but I'm aiming to build ppm packages for