Re: DebToo: Debian, Gentoo-style
Diego Calleja =?ISO-8859-15?Q?Garc=EDa?= <aradorlinux@yahoo.es> writes:
> El Wed, 27 Aug 2003 22:22:28 +1000 Glenn McGrath <bug1@optushome.com.au> escribió:
>
> > Source based distro's are more bandwidth friendly as the source can be
> > reused to produce new revisions of existing packages.
> >
> > As a developer i would _much_ rather have a cache of old source code
> > than a cache of stale binaries.
>
> Or not. For sid I'd choose binary; woody would benefit from source. I think.
>
> Take into account the time you waste compiling. What do you want to
> pay, bandwith or CPU usage? The answer isn't the same for everybody...
> (if we want to touch perfection)
And calculate the amount of time you need to run the programm (if its
faster at all) to save the time spend compiling it.
> > USE settings are the best packaging innovation since apt.
> >
> > Optimised binaries wont run slower than non-optimised binaries.
>
> It depends a lot of what "optimizations" you do. (It'd be interesting
> to measure gentoo's systems compiled from scratch with -O3. They even
> compile kernels with -O3; this has been measured and kernels are slower)
Which holds true for many cases.
> The main problem with debian vs optimizations is that we compile for i386
> code, which sucks. Most of the debian people use i586/i686 systems today.
> Why are we compiling code for a small minority that still uses a 486 as
> routing box? I386 could very well be a subproyect. I don't think
> any i386 needs X 4.3 with gnome/kde, so why are providing binaries
> optimized for a machines which aren't going to use them?
Actually Debian does not support i386 anymore for compatibility
reasons with other linux distriibutions. You canget the basics running
but anything that uses c++ will fail. And whats Debian without apt?
I'm not sure how much, if at all, would be gained by compiling
everything for i486.
Also note that for some cpu intensive libraries optimized versions are
used, like openssl. Debian supports that fully and if you have another
candidate talk to the maintainer. Its easy to do and in the case of
openssl the speed improvement was a factor of 11 iirc for the most
drastic arch.
> > We have the begginings of support for user optimised binaries, but we
> > have a long way to go before catching upto gentoo.
> >
> > We shouldnt be so wrapped up in our own importance that it blinds us to
> > the community. Gentoo is doing something right.
>
> I'm already doing optimised binaries in Debian. It's already there
> (Just too complex).
>
> I don't like gentoo 100%. It does some good things, but it doesn't do most
> of them in the right way; IMHO.
>
>
> To start with; we don't want to make a distro which has to be recompiled.
> Binary packages are cool for installations.
> (Gentoo could do this as a subset of their system "get that specific
> architecture; get a standard USE selection, make packages and burn a iso
> which installs 100% binary packages")
>
> Some issues with a USE flag for me are:
>
> o USE benefits would have to be measured. What's the cost of everything
> depending of everything? How configurable can be a gentoo system;
> that it can justify a USE flag? Can't we compile things with everything
> compiled in; and just provide binary packages for some specific options?
>
> o It's THE reason why gentoo doesn't provide binary packages.(Actually; gentoo
> could solve this with a good p2p-based distribution system for packages. It'd
> be also cool to have a p2p method for apt and download optimised binaries...
> we could keep the MD5s at debian.org and check against them before installing)
Its being thought about / worked on. An extension of bittorrent in
this case.
> o If you change a flag in a package; you should recompile all the dependencies.
> This is important. This makes reconfiguration of a system REALLY _hard_ (Gee,
> I got this new hardware which supports X feature and now I'll recompile 200
> libraries). Do we want this just to get a 'better' package system?
That shouldn't be so harsh. The libraries iterface should stay the
same when changing just minor flags and when you add more libs to be
linked into the lib (say adding jpeg support ot imagelib) all apps
should eigther depend on the libjpeg and get recompiled that way or
should not have to care.
Most flags can be handled internally in a package or autoprobed at
runtime.
It would still be hell to get a dependency moddel for it and get it
right. Far too many combinations to test to notice all bugs.
> o If at the end you need a USE flag because it allows a good configuration;
> what you really should do? Write a new package system because apt sucks?
> Or fix your software because it doesn't allow dynamic configuration of some
> settings?
>
> (NOTE: I'm not suggesting gentoo sucks; just wondering what people thinks...)
>
> o I've other things in mind, but I've to sleep.
>
>
> (I think at the end we'll come with this conclusion: There're different people
> and different needs and both distros have to live together)
>
> Whatever we do: It's much easier to create whatever package system you want and
> migrate to them inside debian, than creating a new distro and all the
> infrastructure it requires.
What would be good would be more gentoo like support in apt. A
gentoo-debian (debtoo?) package could provide all the setup for a
local autobuilder and use hoocks into apt to get packages compiled for
an install or upgrade.
What could also be done is to install the debian bins just like now
but then go and fetch sources and rebuild packages in the background
and replace the installed software. That way you have an instant
upgrade to newer versions and after a while you get the optimized
flavour.
But thats something you can already do with a little configuration.
MfG
Goswin
Reply to: