[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: distinguish between "core" and "main"?



On Sat, 04 Jun 2011 17:07:26 +0200
Harald Dunkel <harri@afaics.de> wrote:

> On 06/04/11 12:36, Neil Williams wrote:
> > On Sat, 04 Jun 2011 10:12:42 +0200
> > Harald Dunkel <harri@afaics.de> wrote:
> > 
> >> Installing testing for the whole system is no option. The base
> >> system (the core packages) should be provided by the most recent
> >> release. I don't want to get an unbootable system.
> > 
> > You are more likely to get a problematic system by MIXING versions than
> > you are by sticking just to stable or just to testing. Unbootable is
> > fairly unlikely (boot loader bugs aside).
> > 
> 
> About the package set dependencies:  The core package sets would be
> self contained, 

They are not, currently. That's a large amount of work and I don't see
any volunteers for that.

> i.e. they would not depend upon packages outside of
> their own core set. The new main/testing repository would be meant
> to work with both core/stable and core/testing.

Tested by whom?

You want quality, that means real people testing real combinations on
real hardware whilst trying to get real work done, not some automated
dependency check. 

Packages only show the full range of bugs when there are enough users
to use each combination of options and methods.

> Using some very rough numbers:
> Instead of main repositories for stable and testing with 30000
> packages each we would have core repositories for stable and testing
> with 1000 packages each, and a common non-core repository with 29000
> packages, to be used together with both core/stable and core/testing.
> That would be 60000 packages vs 31000 packages.

It's not about package numbers, it is about people - people to test the
combination of packages.
 
> Of course this means testing and fixing things for some packages.
> Compatibility is a quality criteria.

Testing compatibility is the larger problem. Automated tests can only
go so far. Dependencies are one thing, bugs which arise because one
setup is using a version which has already been replaced in testing.

> > If you sincerely want the Debian system which has had the most testing
> > of all possible variants and which Debian can honestly describe as "the
> > most likely candidate for a system where packages work together as
> > nicely as it is practical to achieve" you MUST use stable and then keep
> > that up to date with the stable point releases and security updates.
> 
> The problem with this is Debian's long release cycle (+2 years, as it
> seems). Its difficult to get help from upstream if the source code in

Then use chroots, as explained in my first message but which you appear
to have ignored.

I do this every single working day. I run a number of boxes using
stable - each has pbuilder support for sid and most have pdebuild-cross
support for cross-building for armel based on stable or unstable.

The long release cycle arises from the very thing you appear to cherish
- the quality and stability of the stable release. It takes time and
people to generate quality. That's the entire problem - there are not
enough people to do that testing twice over.

Pushing an artificial division into that where only a tiny fraction of
users actually use that particular combination of packages undermines
the entire objective of using stable in the first place. Some people
choose to use mixed systems, there are not enough of those to assure
quality of such combinations.

That is why others here have recommended using testing in the first
place if you want to genuinely build packages on testing due to the
versions of the dependencies you need.

> >> Making this scheme work would imply more frequent releases for the core
> >> packages, but I am sure this can be done. I would expect that we would
> >> get <1000 core packages.
> > 
> > No, it would require huge numbers of testers to use each possible
> > permutation as their daily use systems across all of the fields in
> > which Debian is currently used. If not, then the alternative can never
> > be as good as the current stable release and the whole exercise is
> > pointless.
> 
> Looking at today's testing and stable repositories with about 60000 binary
> packages per platform, and the suggested core/stable, core/testing and
> main/testing repositories with about 31000 binary packages per platform,
> how many permutations would you expect for each scheme?

Testers = people. There are as many permutations as there are testers -
or if you really want the figures, work out how many possible
permutations there are for installing 1,500 packages out of a total
selection of 31,000. Then find people to test each permutation on a
daily, regular usage basis - ensuring that each person fully tests
EVERY application in their particular set.

Completely unrealistic because we already have that for the current
single permutation - it's what gets into stable.

Even a single permutation DOUBLES the number of people running Debian.
I'm not against that, I just don't think it is realistic.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpgE5iP2ALGp.pgp
Description: PGP signature


Reply to: