Re: Some observations regardig the progress towards Debian 3.1
+++ Yann Dirson [03-11-18 22:54 +0100]:
> On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:
> But that last point raises another issue: does anyone really use
> testing ? Would anyone use pre-testing after all ?
I used testing for a couple of years on my laptop and non-critical machines.
I found it a satisfactory compromise between the 'too old' of stable and the
massive churn, ever-changing packages and general need-for undating and
maintenance of unstable.
The primary reason I changed was the 'no security for testing' problem. So I
have moved them both to unstable, but it's a lot of extra work and downloads
for little gain (I get new packages sooner which is interesting but rarely
actually useful) - the only other advantage I get (and the secondary reason
I changed) is that I can do test-builds of my packages before uploading on
an unstable machine. Doing my builds on a testing machine, then uploading to
unstable can mean I introduce packages compiled against the wrong library
versions. Source-only uploads would solve this and I could do test-compiles
on some debian machine.
So I'd say yes, testing is useful to real people, especially those with
low-bandwidth net connections but for whom stable is a bit too old. The only
thing we need to change to make it more widely useful is to make security
updates happen for it in a timely fashion. That would be a sensible use of
resources I think. More people using testing ought to help keep it
releasable.
> > Is testing actually worth the effort?
> 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
Could someone explain to me why this is the case? Was it an attempt to get
things into testing faster that if build-deps were honoured, or was it just
expediency. It does seem more sensible to enforce build-deps too to me, but
I may be missing something.
> - insufficiently-narrowed deps, causing stuff to migrate where it
> should not
> => this looks like a real non-trivial problem to me. Ideas anyone ?
Obviously it can be tricky for a maintainer to get right as they can't
necessarily try all (any!) of the possibilities but it should be aspired-to.
On the other hand, in my experience build-deps are sometimes
unecessaily-narrowed and require new versions of things for no particular
reason I can determine. I suspect the shlibdeps automation contributes to
this?
> > 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...
It's all a compromise, but it's a useful compromise IMHO. It makes sense to
me to view testing as a releasable version of unstable and try to keep it
that way as much as possible. Build-deps being added to the
unstable->testing migration criteria seems to me to be the most fundamental
change needed to make that more true, and security support to make it
practical for people to use/test in the real world.
All the above IMHO as I don't claim to have a deep understanding of all the
dependency and trnsitionning issues. I do have an interest in consistent
buildability for embedded Debian though.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: