Le Fri, Oct 09, 1998 at 08:29:27AM -0400, Michael Alan Dorman écrivait:
> I think you should read the docs or follow the last couple of years of
> the perl5 development mailing list, as I have, before you suggest you
> know better than I. From doc/perldelta.pod:
I apologise, I did not want to sug
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait:
> > Threaded perl and non-threaded perl are binary-incompatible at the
> > extension level, meaning most compiled extensions must be
> > distinguishable.
> I think you're wrong. per
Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait:
> Threaded perl and non-threaded perl are binary-incompatible at the
> extension level, meaning most compiled extensions must be
> distinguishable.
I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible.
Bu
John Lapeyre <[EMAIL PROTECTED]> writes:
> However, at least part of their rationale for the new scheme is to
> allow multiple versions of perl, a feature that debian is not
> interested in.
Threaded perl and non-threaded perl are binary-incompatible at the
extension level, meaning most compiled e
On Fri, 9 Oct 1998, Gergely Madarasz wrote:
> On Thu, 8 Oct 1998, Santiago Vila wrote:
>
> > 2) Are we really going to freeze slink in 7 days?
>
> I dont think we should freeze until we have a broken libc in slink...
^
Hmpf... I meant while :)
--
Madarasz Ger
On Thu, 8 Oct 1998, Santiago Vila wrote:
> 2) Are we really going to freeze slink in 7 days?
I dont think we should freeze until we have a broken libc in slink...
--
Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED]
It's practically impossible to look at a penguin and
On Thu, 8 Oct 1998, Michael Stone wrote:
mstone>What I'm trying to say is "why doesn't perl look in /usr/lib/perl5
mstone>anymore?" Was this just a gratuitous change, or was there a reason for
mstone>breaking things? I can understand the change if there are modules that
mstone>work in 5.004 but not
On Thu, 8 Oct 1998, Richard Braakman wrote:
dark>That "only" is a large source of packaging bugs. In fact, the (IMO)
dark>most annoying upgrade problem in hamm was a pathname problem: two
dark>packages had moved to a different directory at the last minute, and
dark>the auto upgrade script hadn't
Quoting Martin Schulze ([EMAIL PROTECTED]):
> Michael Stone wrote:
> > Except that this isn't what's happening; the new perl is ignoring
> > /usr/lib/perl5. (E.g., I couldn't install netstd the other day because
>
> That's the main cause of this thread...
>
> > it couldn't find DebianNet.pm--whic
On Thu, Oct 08, 1998 at 05:53:39PM +0200, J.H.M.Dassen wrote:
> > 2) Are we really going to freeze slink in 7 days?
>
> Yes.
Oops, I better hurry with my pending iceconf upload. :-)
Michael
--
Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant |
> Does this mean also "no new documentation"?
No.
> For slink, I plan to provide the texi2html-converted HTML for all my GNU
> packages, which means a new package foo-doc for every GNU foo package.
> Do I absolutely have to do this before the freeze? Will all my foo-doc
> packages be rejected be
On Thu, 8 Oct 1998, Brian White wrote:
> The general guideline for "frozen" is:
>
> no new code
>
> A recompile with a new package is fine. Fixes to make something work with
> a change in another package is also fine.
Does this mean also "no new documentation"?
For slink, I plan to prov
> > 1) Don't we have to recompile all our ncurses-based apps against 4.2?
>
> If we want all the ncurses-based apps to use the same version of ncurses,
> yes. I'm not sure if we have to, though if I were the release manager, I
> wouldn't release 2.1 before all ncurses-based apps used the same vers
On Thu, Oct 08, 1998 at 05:53:19PM +0200, Santiago Vila wrote:
> 1) Don't we have to recompile all our ncurses-based apps against 4.2?
If we want all the ncurses-based apps to use the same version of ncurses,
yes. I'm not sure if we have to, though if I were the release manager, I
wouldn't release
On Thu, 8 Oct 1998, Martin Schulze wrote:
> When slink is released it's time to break sid.
I guess you mean here "it's time to break [codename for 2.2 (or 3.0)]".
(By definition, sid will never be released).
--
"ad283d11c8d64562db7796279c3f4be8" (a truly random sig)
Hi.
1) Don't we have to recompile all our ncurses-based apps against 4.2?
2) Are we really going to freeze slink in 7 days?
I see that 1) and 2) don't mix very well.
--
"76975153d9e889b854dd4ae6c231f5e9" (a truly random sig)
Le Thu, Oct 08, 1998 at 02:42:59PM +0200, Richard Braakman écrivait:
> itself will break. People will be upgrading from hamm to slink when
> we release it, and they will run into problems like update-inetd
> breaking halfway through a mass upgrade.
This would not be the case when packages will be
Previously Martin Schulze wrote:
> Speaking of the upgrade script, is there *any* reason why
> /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't
> run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh
> since Sep 5th?
Possibly the same reason nothing has
Richard Braakman wrote:
> Raphael Hertzog wrote:
> > Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait:
> > > Another solution would be a) to postpone the freeze for some time or b)
> > > allow fixed perl uploads within the freeze.
> >
> > b) would be fine for me. Because perl uplo
Michael Stone wrote:
> Quoting Martin Schulze ([EMAIL PROTECTED]):
> > Before this screwup I didn't realize that most but not all modules are
> > placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain
> > /usr/lib/per5 would be sufficient, too. We should have made it
> > policy that modul
Raphael Hertzog wrote:
> Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait:
> > Another solution would be a) to postpone the freeze for some time or b)
> > allow fixed perl uploads within the freeze.
>
> b) would be fine for me. Because perl uploads will not introduce any
> securi
Quoting Martin Schulze ([EMAIL PROTECTED]):
> Before this screwup I didn't realize that most but not all modules are
> placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain
> /usr/lib/per5 would be sufficient, too. We should have made it
> policy that modules have to omit the versioned d
Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait:
> Another solution would be a) to postpone the freeze for some time or b)
> allow fixed perl uploads within the freeze.
b) would be fine for me. Because perl uploads will not introduce any
security holes and because packages will
Darren/Torin/Who Ever... wrote:
> >Thus I believe it would need to use (>= 5.005-0)
>
> But it would also have to use (<< 5.006-0).
I don't think this is a problem.
> >(I thought that debian-devel had reached a consensous that it's not
> >a good idea to change the perl version less than 14 days
Raphael Hertzog wrote:
> Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait:
> > Thus I believe it would need to use (>= 5.005-0)
>
> (>= 5.005) should work too, no ?
Check out what dpkg thinks about it:
finlandia!joey(tty5):/tmp> dpkg --compare-versions 5.005 lt 5.005-1; echo $?
>> "RH" == Raphael Hertzog <[EMAIL PROTECTED]> writes:
RH> I don't know what debian-devel reached, but in fact it seems to me
RH> that just a few people are interested by perl. :-)
If you want other voices, then count me to the "5.004 for Debian 2.1"
party. I agree to Joey's arguments.
Ciao,
Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait:
> Thus I believe it would need to use (>= 5.005-0)
(>= 5.005) should work too, no ?
> (I thought that debian-devel had reached a consensous that it's not
> a good idea to change the perl version less than 14 days before
> the cod
On Thu, 8 Oct 1998, Martin Schulze wrote:
joey>(I thought that debian-devel had reached a consensous that it's not
joey>a good idea to change the perl version less than 14 days before
joey>the code freeze.)
Well perl 5.005 is now installed in slink, and when it is
installed, alot of stuf
Darren Stalder wrote:
> Is it possible for dpkg to have a depends line similar to:
> Depends: perl (=5.005)
> and have that include 5.005-\d+? Or will I need to put a
= means equal. I guess it's logical that 5.005 != 5.005-1
Thus I believe it would need to use (>= 5.005-0)
> Provides: perl5.005
-BEGIN PGP SIGNED MESSAGE-
Is it possible for dpkg to have a depends line similar to:
Depends: perl (=5.005)
and have that include 5.005-\d+? Or will I need to put a
Provides: perl5.005
in so that packages can depend on that?
(Note that I did say that this would break *all* debian instal
30 matches
Mail list logo
