Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
Andreas Barth <aba@not.so.argh.org> writes:
> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [030828 03:50]:
> > Andreas Barth <aba@not.so.argh.org> writes:
> > > We've often had whining here about sid breaking something production
> > > critical. Well, sid is not meant to be used for that, but enough
> > > people do. (In other words: I don't trust the users enough that they
> > > will make the right choices.) So, in theory you're right. In practice
> > > users will manage to break.
>
> > The problem is that woody is to old for many users. Thats why they use
> > sid. Experimental and sid would be just days/weeks apart
> > versionwise. There would be no big need for users to choose
> > experimental.
>
> Really? The latest glibc in sarge is from 2003-03-22, and there are
> currently 1103 packages waiting for glibc.
What has that got to do with anything?
Packages from experimental should never move into sid as said
repeadetly on this thread. And recompiling sources for sid solves any
such mass blockage as caused by a glibc update.
> > > Only way out. But - who wants on-the-fly autobuilding can do that also
> > > now. Perhaps a bit of infrastructure can be added for this (e.g. new
> > > build-depends-headers like:
> > > build-depends-woody: ... which supersede the original b-d header if
> > > builded under woody). But in general you can build packages quite easy
> > > today with apt-get source package, apt-get build-dep package, cd
> > > directory, dpkg-buildpackage -rfakeroot. Perhaps you should package an
> > > easy script for that, but that's all that can be done for that.
>
> > Build-depends are fine for it. It just need some nicer way to set this
> > up for the user. It needs to run with a single command preferably. At
> > the moment you have to do an update, look ast an upgrade (but don#t do
> > it), get sources of all packages and compile, dpkg -i the debs.
>
> #! /bin/sh
> cd /clean/place/to/build
> apt-get update
> apt-get source $1
> apt-get build-dep $1
> cd $1*
> dpkg-buildpackage -uc -b
> dpkg -i ../*.deb
>
> (Well, if you want binary packages to be selectable, you need a few
> more code-lines, same for compiling only when necessary, and for
> better inclusion into normal apt-get-process.)
That pollutes your client with -dev packages. It also removes packages
that build-conflict and it fails quite a lot.
For on-the-fly compiling a chroot is pretty much a must in my opinion.
MfG
Goswin
PS: Seen the "FTBFS: tries to write to /foobar" like bugreports?
Reply to: