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) [030826 21:50]:
> > Andreas Barth <aba@not.so.argh.org> writes:
> > > 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 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.
> > > 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 why I say make it a source distribution. Recompile for the set
of experimental sections selected by the user.
The only other halfway sane choise would be to compile every section
against sid and its own section with all the problems you then get
when mixing in experimental-core libs nearly everything links to.
> > 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.
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.
Alternatively a buildd which is even more work to install.
MfG
Goswin
Reply to: