Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [030826 21:50]:
> Andreas Barth <aba@not.so.argh.org> writes:
>
> > * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [030826 15:20]:
> > > Only those contained in the sections enabled on the users system. If
> > > you have experimental-core and experimental-gnome all gnome debs
> > > should be comnpiled against the experimental glibc for example.
> > This mass-introduces bugs reports of glibc-bugs to other packages. No,
> > glibc (and the other core parts) must be the most conservative part of
> If you are not able to test experimental-core packages properly (like
> glibc) then don't have experimental-core activated on your client.
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 system. (And, I don't believe that a proposal with so many changes
> > to the pool and mirror system has a real chance to be implemented.)
> The pool doesn't change at all. Its a change of the script generating
> the Packages/Sources files (adding a few lines for the new files) and
> a long needed fix for source-only uploads to the mirror maintanace
> scripts.
example: New version of apache in experimental which db5 (instead of
db4.2). With which versions should the modules in libapache-mod-* be
compiled? If you request to take all libapache-mod-* then out of
experimental, you can quite easily transfer this to a newer glibc.
That means that you need experimental-core if you enable anything in
experimental. Discrepance and so q.e.d. for my claim.
> Thats if you keep with building eperimental packages on the fly on the
> client. If not you have a bunch of changes to the autobuilders.
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.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: