Re: libc6-i686 only for 2.6 kernels? was: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 05:21:57PM +1100, Zenaan Harkness wrote:
> On Tue, 2003-11-11 at 15:29, Daniel Jacobowitz wrote:
> > On Tue, Nov 11, 2003 at 05:08:16AM +0100, Dagfinn Ilmari Mannsåker wrote:
> > > Daniel Jacobowitz <dan@debian.org> writes:
> > >
> > > > On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
> > > >> On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> > > >> > And Nikita just pointed out there's libc6-i686. It might make sense to add
> > > >> > linux-i686 too. I'm open for discussing that, but this discussion doesn't
> > > >> > belong on the ITP bug.
> > > >>
> > > >> And why is it only for 2.6 kernels? The processor specific package should
> > > >> support NPTL, and it doesn't require 2.6...
> > > >
> > > > That sentence is contradictory - NPTL requires 2.6.
> > >
> > > But there should be a non-NPTL i686-optimized libc6 too, as in
> > > /lib/i686/cmov/ in addtion to the current /lib/tls/i686/cmov/.
> >
> > Gotta draw the line somewhere. We chose to draw it there.
> >
> > Building glibc four times on x86 hardware seems to be a bit excessive
> > for our needs.
>
> How long does a glibc compile take?
>
> Eg., would just basic i386 binaries, with say a -builder version
> (or script - anything remotely along the lines of gentoo), be a
> better way to optimize packages? For example:
>
> optimize-build --auto-detect-current-platform
> --arch i686 --no-mmx
> my-package-that-really-needs-maximum-optimization
>
> Packages (such as kernel, glibc, gimp) could optionally provide a
> "hints" file with optmized build recommendations (+'ve as well as
> -'ve) which could be overridden, etc.
>
> (I haven't used or looked at gentoo, so I don't know if what I am
> saying is plain silly or not ...)
>
> Such a scheme would have the advantages of:
> - minimizing debian repo size (no custom optimized binary packages)
> - optimal optimization as opposed to lcd/"lowest denominator" optimize
>
> and at least the disadvantages of:
> - not so simple to get optimized build
> (although possibly could configure to auto optimize some packages)
> - optimized-build local packaging scripts would need to be written
> (ie. it doesn't yet exist)
>
> There are surely more (dis)advantages not on the top of my head...
- Bugs caused by specific tool versions would become unreproducible and
even less predictable.
No, thank you. I don't think it's appropriate for Debian to do this.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: