Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
* Goswin von Brederlow (email@example.com) [030828 03:50]:
> Andreas Barth <firstname.lastname@example.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
Really? The latest glibc in sarge is from 2003-03-22, and there are
currently 1103 packages waiting for glibc.
> > 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.
apt-get source $1
apt-get build-dep $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.)
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C