The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which libc should we use in the future?

Helmut Geyer writes:
> David Engel:
> > The way I was going to handle this was to make a special libc5-dev
> > package using libc 5.2.18 which did not depend on the corresponding
> > libc5 run-time package (i.e. the symlinks for libc.so and libm.so
> > would be replaced with real files).  This way, a developer could
> > install this libc5-dev package when needed instead of the normal one
> > without having to downgrade the libc5 run-time package.
> > 
> This is _very_ hard to do (not because of the libs, that's easy) as you have
> to support two include file trees /usr/include fo rthe standard include files.

It's not hard at all.  We just have to two versions of libc5-dev.  A
developer would normally keep the new version installed.  On the rare
occasion he has to update a package for the stable tree, he just has
to install the older libc5-dev, build the package, and then reinstall
the new libc5-dev.  

This is one of the reasons I originally split "library" packages into
separate run-time and development packages.  It gives us the
flexibility to have different versions installed when the need arises.

Yes, it's a bit of a pain, but thanks to our packaging, it's much less
of a pain the alternatives described below.

> They are incompatible.
> There are basically two ways to do this:
> 1.  You would have to make some mechanism like having three directories:
>    /usr/include-5.2.18, /usr/include-5.4.7 and /usr/include.
>    All non-libc includefiles are in /usr/include, the libc includes are
>    managed using an automated script and symlinks.
>    i.e. some script 'turn-on-libc <version>'
> 2. same as above but use -I directives. This is very complicated, as
>    the directory gets appended to the include path, so the gcc includes may be
>    read before the libc include. This can, of course, be changed using 
>    additionally -nostdinc which ahs teh disadvantage that you have to
>    specify the gcc include path explicitly. This could be done using a
>    special gcc script (which is updated when gcc is).
> 3. have a non-standard gcc to support the different structures. This is, IMHO,
>    overkill and shouldn't be done.

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1001 E. Arapaho Road
(972) 234-6400                     Richardson, TX  75081

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com