Re: distinguish between "core" and "main"?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Neil,
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, 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.
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.
Of course this means testing and fixing things for some packages.
Compatibility is a quality criteria.
>> In the new system the main/testing packages should be _guaranteed_
>
> NOTHING in Debian is guaranteed. Not even in a stable release is
> it guaranteed that all packages will work together. Fairly likely, yes.
> Our best effort to achieve as good as we can make it - definitely.
> Guarantee? Impossible. Dreamland. Tell you what, you do all the testing
> and maybe Debian might refund the cost of the software - oh wait....
>
Surely "guaranteed" was the wrong word. Please excuse this mistake.
I didn't mean to upset you.
> 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
stable is 2 years old. Drbd, libvirt and other virtualization solutions,
third party software, etc. are examples. Not to mention hardware
dependencies. Not to mention that the users would like to use the most
shiny new eye candy system of their dreams, and yet assume to get a
stable XWindow server.
>> 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?
Regards
Harri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3qSi4ACgkQUTlbRTxpHjdsfACfblEVtn1XYthjGZrKgKp2F14l
17EAn2cFQxIdZ8yvzgWB6tOSP9PPr0oV
=xrGC
-----END PGP SIGNATURE-----
Reply to: