[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc recompiling was Re: libc resolver problem solved (critical bug)

On Thu, 19 Nov 1998, Gergely Madarasz wrote:

> On Thu, 19 Nov 1998, Michael Meskes wrote:
> > On Thu, Nov 19, 1998 at 10:36:26AM -0500, Dale Scheetz wrote:
> > > I have a fixed package ready to go, so lets move forward!
> > 
> > I agree. But make sure you Conflict with dpkg >= I have 1.4.1
> This would mean it conflicts with all future versions of dpkg... you
> surely don't want that. So several conflicts, with exact version conflicts
> (for dpkg packagages known to be bad) should work. And of course we must
> make sure noone uploads a new dpkg compiled with broken libc.

We are currently looking at excluding libstdc++2.9 <some specific -x>
using conflicts, and now it seems we need a range of dpkg exclusions as
well. This raises two questions:

1. What is the maximum length of a Conflicts: field?

2. Can a range of version numbers be specified, and how?

The Conflicts field on libc6 is already around 65 characters. Every entry
made there must stay "forever".

Does dpkg support a conflicts as a range, or as a boolean exclusion
expression like >=version1 and <=version2?

As another approach, does "==2.0.7u" cover all the -x releases, or must
they be stated explicitly?

Trying to decide how to do this experimentally isn't very cost effective
when it takes over 2 hours to build the package.

In any case, I am not equipped to test all of the effected versions of
dpkg (It isn't any harder than checking the depends field on the package.
I just don't have access all the versions.)

I am currently running, which runs fine in all three library
conditions (else I never could have gotten to this point myself). As this
is the hamm release dpkg, this is good news. There will be no problems
upgrading hamm to slink. The only problems that we are dealing with here
are the pre-release versions of some packages.

I would appreciate reports from others. I need to know what versions of
dpkg depend explicitly on 2.0.7u glibc. I also need to know the
latest version of dpkg. We should also be sure that there is not another
version of dpkg about ready for release. (I CC'd this to the dpkg
maintainer address) In addition, once the fixed libc is released we need
to get a fixed version out ASAP. As it will only require a recompile
against the fixed library, this should not be an excessive hardship on the

Within 3 hours of knowing how to write the conflicts lines, I can have a
new version uploading to master.

Waiting is,

_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Reply to: