Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
On Tue, Sep 14, 1999 at 02:32:56PM +0200, Paul Seelig wrote:
> bortzmeyer@pasteur.fr (Stephane Bortzmeyer) writes:
>
> > That's a big difference between Debian and FreeBSD: FreeBSD cares only
> > about the base system. Ports ("source packages") and packages are
> > irrelevant for them, as far as release is concerned. (FreeBSD does not
> > have a unified package database, since the base system is not a
> > package, so item 2 cannot hurt them. Ports are not supposed to write
> > in / or /usr so item 1, in theory, is not a risk for them.)
> >
> > Debian, on the other hand, ships a system, not just a base + a random
> > collection of ports.
> >
> The more and more i think about it, i'm getting convinced that Debian
> should follow a similar path like FreeBSD. In order to get rid of the
> hard to manage monolithic system we currently have we should probably
> better split it into a core Debian system and add-on packages (which
> could possibly be shared between stable and unstable), but both under
> the usual bug tracking system's quality control and with official
> maintainers. The one big problem i see though is if it is at all
> feasible to untangle the system and divide it into subsections.
Why not divide our current main in three parts :
* debian/main/core : will contain the minimum for a complete developpment
system : Most of base, gcc, full perl, g++, binutils, kernel source, apt and
dpkg, libc, plus any stuff they depend on. Ideally this would be less than
100MB so as to fit on zip disk.
* debian/main/part-2 : will contain a lot more stuff, but will fit in 650MB,
together with core and the disk and install stuff. It would be self
contained, and we can then use it to give free debian CDs and other such at
linux events, or with some magazine. Or even as big boot floppies.
* debian/main/part-3 would contain the rest of what is now main and didn't fit
in the two above parts.
The first part (called core here) will be closely monitored, and no long
standing bugs will be allowed in it. When we decide to go for a new release, we
first freeze it, decide what packages go in, which version of glibc, gcc,
kernel, policy and so on. Once that is done, The bugs are ironed out, and it is
released as debian-released-alpha or whatever.
Now every developper that maintains packages in other parts of main or in non
main, can download it, set up a small chrooted environment, or a new partition
for it, and begin porting his packages, first the one in part-2, then the ones
in part-3 and non-free and contrib. (the part-2/part-3 distinction is solely to
make 1 binary cd sets.).
We freeze the core part every 3-4 month, and then people start porting the
other package to it, while the core maintainer work on the next release of the
core stuff, and fix any new bug that appear in the old core.
This mean the core packages will be maintained by active developpers only,
maybe even a team of maintainer for every big part, so as to get bug fixed
quickly. If the maintainer disappear or is unavailable for whatever resaon, NMU
are made to fix it, and a new maintainer is sought to assure the work.
Friendly,
Sven LUTHER
Reply to: