Re: Some observations regardig the progress towards Debian 3.1
On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:
> There are some good suggestions in your proposal, e.g. you suggest to
> check whether the build dependencies are fulfilled. The lack of checking
> for build dependencies in the current testing scripts often leads to
> packages in testing you can't build inside testing.
Sure, and that can probably be added to testing scripts right now,
isn't it ?
> But you have to be aware that your proposal only works for the cases
> where the programs actually compile and work with older versions of
> libraries, the big tasks like getting KDE 3, GNOME 2 or a more recent
> Mozilla into testing aren't affected by your suggestion.
Yes. We could think about having a fast low-cost buildd (ie. i386)
initiating the build that will eventually migrate, and build arch-all
debs. Only if that succeeds will other buildds start their work. If
that initial build fails, then the unstable version has to be flagged
on-hold, and attempted again when one of its builddeps has been promoted.
But that would not handle the "and work" part of your statement. For
this we'd need to be able to declare testsuites to be run (this has
been discussed recently, IIRC, although I missed the thread).
But more importantly, if a program deos not "compile and work with
older versions", then it's a case of insufficiently-narrowed
build-dep, and we'll have the same type of breakage that we have today
with insufficiently-narrowed deps. Could anyone using "testing" (how
much people use testing ?) share his feelings about the frequency of
such breakages, and how it evolved since testing exists ? That could
give a hint whether this is a showstopper or not.
But that last point raises another issue: does anyone really use
testing ? Would anyone use pre-testing after all ?
And if we can make testing usable enough so that people do use it,
what incentive would there be to use pre-testing ?
> There might be new problems e.g. with inter-library dpendencies for
> libraries without versioned symbols if your proposal would be
> implemented.
Hm ? I'm not sure I understand what the problem you mention is.
> > There _are_ many things to think about, but it may be worth to
> > investigate it, and see how we could handle the potential problems we
> > can think of.
> >...
>
> There's also a different discussion that should take place:
>
> Is testing actually worth the effort?
>
> Testing has it's benefits, e.g. it catches build errors and dependency
> problems.
So what about looking for solutions for the problems ? If we drop
testing, what do we do instead ? Go back to evolving-unstable ->
frozen -> stable ?
> After three years of testing, it seems that some of the promises like
> having testing always in a releasable state were never fulfilled, in
> fact testing was sometimes in a worse state than unstable.
I suppose many of use have a number of problems to mention. Could we
just (attempt to) list them all, and see if they can be fixed easily ?
Or if they require some in-depth restructuring ?
I'll start with:
- build-deps are ignored, causing unbuildable stuff
=> handle build-deps in exactly the same way deps are
- insufficiently-narrowed deps, causing stuff to migrate where it
should not
=> this looks like a real non-trivial problem to me. Ideas anyone ?
- non-buggy packages are held forever, sometime because of very
distant packages blocking them indirectly
=> my pre-testing proposal was written to address precisely this, but
as mentionned above, it's not perfect either
> testing with its lack of security fixes, aprox. 500 RC bugs and daily
> changing packages is not usable for production systems.
What's the problem with daily changing packages ? By nature, only
different packages can change each day. That could make it a good
compromise between stable and unstable, eg. for people in need for
up-to-date desktops. But precisely, one of the problems for those
people, is that _some_ packages _do_not_ change rapidly enough...
Regards,
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
Pro: <yann.dirson@fr.alcove.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Reply to: