On 21/07/11 20:27, David R. Morrison wrote:
> OK. I just did a test build of our perl5100 package and it failed, so needs
> work.
>
> So for now, we'll let things be, but if somebody wanted to work on perl
> 5.10.0 to bring it forward, they are welcome to do it.
For what it's worth, Lion has /u
Going the other way, we may want to add a perl5.12.3 to 10.[56] to help
promote keeping the older dist's -pm packages updated as more
developers switch to 10.7 as their primary target.
dan
On Thu, 21 Jul 2011 11:27:36 -0700, "David R. Morrison" wrote:
OK. I just did a test build of our perl5
OK. I just did a test build of our perl5100 package and it failed, so needs
work.
So for now, we'll let things be, but if somebody wanted to work on perl 5.10.0
to bring it forward, they are welcome to do it.
I'll follow the received advice and not bring perl 5.8.8 forward.
-- Dave
On Jul
> "David" == David R Morrison writes:
David> What about perl? Should we bring perl 5.8.8 forward, or leave it
David> out?
http://www.nntp.perl.org/group/perl.perl5.porters/2008/11/msg141328.html
5.8.x is EOLed already. 2.5 years ago.
--
Randal L. Schwartz - Stonehenge Consulting Service
On Thu, 21 Jul 2011 11:00:03 -0700, "David R. Morrison" wrote:
In a discussion on irc this morning, there was a general consensus to
bring Python 2.6 and 2.7 forward to 10.7, but not to bring Python 2.5
forward. I subsequently put the python26 and python27 packages into
the 10.7 tree.
>
> Wha
In a discussion on irc this morning, there was a general consensus to bring
Python 2.6 and 2.7 forward to 10.7, but not to bring Python 2.5 forward. I
subsequently put the python26 and python27 packages into the 10.7 tree.
What about perl? Should we bring perl 5.8.8 forward, or leave it out?
We don't *always* have to share files. In the case of xmkmf I plan to
create different versions for the different trees. I'll probably put
the Distribution labels there just to remind myself what they are
intended for.
-- Dave
On Jul 21, 2011, at 10:09 AM, Jack Howarth wrote:
> On Thu
On Thu, Jul 21, 2011 at 09:45:05AM -0700, David R. Morrison wrote:
> Jack,
>
> Many of our package maintainers will now be faced with trying to
> maintain a package across several distributions, and in cases where
> there doesn't need to be a difference, the maintenance is easier if the
> foo.
Jack,
Many of our package maintainers will now be faced with trying to
maintain a package across several distributions, and in cases where
there doesn't need to be a difference, the maintenance is easier if
the foo.info files are identical.
So generally, copying the same version, revision,
Some consensus should be arrived at on how revisions should be set in the
10.7
tree relative to 10.4-EOL/10.4(aka 10.5). For example, take the package foobar
which
in 10.4 may have...
foobar.info with
Version: 1.0
Revision: 1000
foobar-x86_64.info with
Version: 1.0
Revision: 1001
Architect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/21/11 9:02 AM, Jack Howarth wrote:
> Dave, Is it possible for us to drop "Type: -64bit" from 10.7, yet
> retain the ability to properly package 32-bit shared libraries?
> Perhaps since we no longer have to distinguish between a 32-bit
> package wi
Dave,
Is it possible for us to drop "Type: -64bit" from 10.7, yet retain the
ability to properly package 32-bit shared libraries? Perhaps since we no longer
have to distinguish between a 32-bit package with 64-bit files and a 64-bit
package with 32-bit files, this issue is easier to solve in fi
12 matches
Mail list logo
