'Remco Blaakmeer wrote:'
On Sat, 13 Dec 1997, David Engel wrote:
Definitely not! libc5-dev implies that libc5 is the default
compilation environment installed in /usr/include.
Sorry, I must have been half asleep when I wrote the above. libc5-altdev
doesn't have to conflict with either
'Scott K. Ellis wrote:'
On Fri, 12 Dec 1997, Chris Fearnley wrote:
Why can't we do the following:
In both bo-updates and hamm:
libc5: No conflicts, no depends (predepends on ldso, of course)
(solves the problem of not being able to upgrade easily)
[...]
This still forces people
On Sat, 13 Dec 1997, David Engel wrote:
On Sat, Dec 13, 1997 at 11:47:50AM -0500, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
hamm: libc5-altdev, depends on hamm-libc5,
OK.
conflicts with bo-libc5-dev and
hamm-libc6-dev,
Unnecessary.
provides
Chris Fearnley [EMAIL PROTECTED] writes:
'Martin Mitchell wrote:'
The 5.4.33-6 package is _not_ broken, and should not be removed.
It rightly conflicts with libc6 due to the different utmp format between
libc5 and libc6. The 5.4.33-7 package in hamm has modified utmp routines
so it can
'Martin Mitchell wrote:'
Chris Fearnley [EMAIL PROTECTED] writes:
Is breaking easy upgradeability really better than corrupting utmp?
Yes, it means the system should work properly at all stages of the upgrade.
Still, the fact that libc5-5.4.33-7 conflicts with libc5-dev means that
I have to
Question:
Would it possible to make a (not altdev):
debian/dists/unstable/main/binary-i386/oldlibs/libc5-dev_5.4.33-7.deb
that conflicts with libc6-dev? And would this solve everyones problem?
I'm just wondering if the libc5 in this directory doesn't have problems
with the utmp.
Thanks,
Scott Ellis [EMAIL PROTECTED] writes:
Installing libc5 from hamm forces you to abandon your old libc5
development system since it CONFLICTS (correctly) with libc5-dev. Not
everyone is going that route yet.
True, so they can stay with bo for now.
Okay there is a different utmp format. Lets
On Sat, Dec 13, 1997 at 01:44:51PM +1100, Martin Mitchell wrote:
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not, especially if I expected that staying with
'Martin Mitchell wrote:'
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not, especially if I expected that staying with
mainly bo would give me a stable system. No one
On Fri, 12 Dec 1997, Chris Fearnley wrote:
'Martin Mitchell wrote:'
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not, especially if I expected that staying with
On Sat, 13 Dec 1997, Scott K. Ellis wrote:
On Fri, 12 Dec 1997, Chris Fearnley wrote:
Why can't we do the following:
In both bo-updates and hamm:
libc5: No conflicts, no depends (predepends on ldso, of course)
(solves the problem of not being able to upgrade easily)
In
On 13 Dec 1997, Martin Mitchell wrote:
Scott Ellis [EMAIL PROTECTED] writes:
Installing libc5 from hamm forces you to abandon your old libc5
development system since it CONFLICTS (correctly) with libc5-dev. Not
everyone is going that route yet.
True, so they can stay with bo for now.
On Fri, 12 Dec 1997, Brandon Mitchell wrote:
Would it possible to make a (not altdev):
debian/dists/unstable/main/binary-i386/oldlibs/libc5-dev_5.4.33-7.deb
that conflicts with libc6-dev? And would this solve everyones problem?
I'm just wondering if the libc5 in this directory doesn't
On Fri, 12 Dec 1997, David Welton wrote:
On Sat, Dec 13, 1997 at 01:44:51PM +1100, Martin Mitchell wrote:
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not,
On Fri, 12 Dec 1997, Joe Emenaker wrote:
On 12 Dec 1997, Rob Browning wrote:
Scott Ellis [EMAIL PROTECTED] writes:
I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE
NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO
THROUGH HELL.
Say
On 12 Dec 1997, Rob Browning wrote:
The problem is that maybe *you* know what packages those are, but most
users expect to be able to upgrade without major system services
breaking if dpkg/dselect doesn't indicate that there's a problem.
Your approach would cause silent failures.
Imagine
On Sat, Dec 13, 1997 at 01:11:37AM -0500, Scott K. Ellis wrote:
On Fri, 12 Dec 1997, David Welton wrote:
On Sat, Dec 13, 1997 at 01:44:51PM +1100, Martin Mitchell wrote:
Isn't this the whole point of compiling hamm packages for bo? Ie, the
bo-updates, bo-current or whatever directory that
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
(Necessary due to utmp issue -- Hell, someone upgrading from a CD
with stock 1.3.1 will be able to corrupt utmp in the current scheme
anyway!)
On Sat, Dec 13, 1997 at 01:06:07AM -0500, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
Would it? What if they would also upgrade their libc5-dev to the same
version as the libc5 in hamm? Would that help? In the past these two
packages always had to have the same
On Sat, 13 Dec 1997, David Engel wrote:
On Sat, Dec 13, 1997 at 01:06:07AM -0500, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
Would it? What if they would also upgrade their libc5-dev to the same
version as the libc5 in hamm? Would that help? In the past these two
Scott K. Ellis [EMAIL PROTECTED] writes:
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
(Necessary due to utmp issue -- Hell, someone upgrading from a CD
with stock 1.3.1 will be able to
On 13 Dec 1997, Martin Mitchell wrote:
Scott K. Ellis [EMAIL PROTECTED] writes:
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
(Necessary due to utmp issue -- Hell, someone upgrading
Scott K. Ellis [EMAIL PROTECTED] writes:
On 13 Dec 1997, Martin Mitchell wrote:
Scott K. Ellis [EMAIL PROTECTED] writes:
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
David Engel [EMAIL PROTECTED] writes:
So find someone to modify the libc5 in hamm to build both -dev and
-altdev packages. It isn't that hard.
That's really the only workable solution.
David, I do think you ought to add the Conflicts to older versions of
libc5 to libc6. This will prevent
On Sat, 13 Dec 1997, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
On Sat, 13 Dec 1997, Scott K. Ellis wrote:
This still forces people installing libc6 to upgrade libc5 past a version
that can be used with libc5-dev.
Would it? What if they would also upgrade
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
On Sat, 13 Dec 1997, Scott K. Ellis wrote:
The problem is that libc5-dev doesn't exist in hamm. Hamm has
libc5-altdev instead. This forces people who want to compile libc5 stuff
into the altgcc/lib*-altdev mode, requiring the mass removal and
On Sat, Dec 13, 1997 at 01:37:04AM -0500, Scott K. Ellis wrote:
So find someone to modify the libc5 in hamm to build both -dev and
-altdev packages. It isn't that hard.
Trust me, if I thought I was competant enough to do so, I would. However,
I don't trust myself not to break such an
On Sat, Dec 13, 1997 at 11:47:50AM -0500, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
hamm: libc5-altdev, depends on hamm-libc5,
OK.
conflicts with bo-libc5-dev and
hamm-libc6-dev,
Unnecessary.
provides (probably) libc5-dev
Definitely not! libc5-dev
Moved to debian-devel
'Scott Ellis wrote:'
On 13 Dec 1997, Martin Mitchell wrote:
Wichert Akkerman [EMAIL PROTECTED] writes:
Huh? The upgrade path is quite clear: install a newer libc5 (5.4.33-7)
from hamm, then you may install libc6.
Maybe we can fix this by making libc6
On Fri, 12 Dec 1997, Chris Fearnley wrote:
Actually, I think Martin is correct. In order to prevent CDROM based
1.3.1 users from corrupting their utmp, libc6 must conflict with older
libc5. Modulo my typo (Martin's = is right, not my ), I think my
other post suggests the best solution. Of
'Rob Browning wrote:'
Scott Ellis [EMAIL PROTECTED] writes:
If you don't upgrade anything that deals with utmp to libc6, you
don't have any problems).
The problem is that maybe *you* know what packages those are, but most
users expect to be able to upgrade without major system services
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
Why should libc5 conflict with libc5-dev??
It doesn't need to. The explicit version dependency in libc5-dev is
sufficient.
Would this scheme improve things:
libc5 (stable,unstable): No conflicts, no depends (pre-depends on
On 12 Dec 1997, Rob Browning wrote:
Scott Ellis [EMAIL PROTECTED] writes:
I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE
NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO
THROUGH HELL.
Say you're an ISP running Debian (bo) on a bunch of machines
33 matches
Mail list logo
