Idea: Debian Release Sections
In my previous email (Debian-Devel, subject "Debian Critical Mass") I
commented on how I believe that Debian has arrived at somewhat of a
state of critical mass. I base this upon the number of packages
available in Debian, the recognition Debian is getting nowadays for the
excellent distribution it is, the interest being shown across the
Internet to package stuff as Debian packages, and so on. I also
suggested an adaption to the current Debian repository
way-of-doing-things that I believe would be beneficial. The purpose of
this email is to take that concept into a little more detail.
The "Radical" Suggestion
------------------------
I believe that the main/contrib/non-free way of doing things is just not
flexible enough to accomadate the needs of the Debian of today. When
Debian was young, main/contrib/non-free was a very nice split for the
distribution. Nowadays, however, the distribution has grown to the size
that a further split is really quite necessary.
The basic concept of this idea would be to split main up into a series
of smaller sections. These contents of each of these sections would be
dependant upon either one or two deciding factors.
The first of these factors is release frequency. Currently, all Debian
packages are released at the same rate. This occurs, of course, in the
blue moon when Debian makes another major or minor release of the
distribution as a whole. This means that debian packages containing
software that is very dynamic may sometimes be many months (or even a
year) behind the main software distribution. Generally speaking (without
going on forever and giving a great number of specific examples) there
is just a MAJOR unbalance in the Debian distribution between packages
need for more and less frequent updates.
The second of these factors would just be a concept of similarity. This
further breakdown of packages is based would be present to make each
release section be a little bit smaller. This is necessary to allow each
section to be released based upon individual frequency needs. If a
section is allowed to grow to large, the number of packages that it
contains will stop it from being released on its necessary schedules.
Anthony Towns brought up a very good point concerning the coordination
of these various releases:
> This could work, perhaps. It's not really clear how the
> coordination problems could be solved though: if one
> section freezes for two months and then releases, but
> has to stay frozen for another two months while another
> section freezes and then releases, and then both of those
> have to stay frozen for a further two months while another
> releases, that's not much better than currently.
This is an issue which would have to be carefully looked into in order
to find an acceptable solution. I believe the basis for the solution to
this issue would be as follows.
There would have to be some core sections that were the "important"
ones. These sections would contain more of the supporting framework of
the Debian distribution. This would include packages such as perl,
common libraries, etc.
Core Sections: (examples)
--------------
Debian-Core: Includes the collection of packages which make debian,
debian. This would include everything from package installation tools,
to Debian boot process packages (init scripts, etc), Debian network
setup packages, etc
Release Freq: approx. 3-6 months (depending on current development)
Example Packages: dpkg, apt, netbase
Debian-CoreTools: Includes packages which are not debian specific, but
still mission critical. This would include package collections such as
everything needed to make perl work.
Release Freq: approx. 2-6 months (depending on current development)
Example Packages: perl
Debian-CoreOS: Includes the collection of packages which make up the OS
portion of Debian. This would include shells, core libraries, etc.
Release Freq: approx. 2-6 months (depending on current development)
Example Packages: bash, libc, cron
Debian-CoreX: Includes the collection of packages which make up the X
Windowing System.
Release Freq: approx. 2-6 months (depending on current development)
Example Packages: all the X stuff
And there could probably be others. These are just some examples.
Other Sections: (examples)
--------------
Debian-RapidDevel: Rapid Development packages. This packages change
often and need to be released more often.
Release Freq: 1-2 months
Example Packages: ???
(can't think of a good example, but there are many out there)
Debian-Net: Debian packages involving networking. This does not include
basic networking packages, as they would fall into one of the core
sections. However, this would include web servers, ftp servers, etc.
Release Freq: 3-6 months
Example Packages: apache, wu-ftpd
Debian-Static: Group of Debian packages containing software that is not
being actively upgraded, etc.
Release Freq: 6-9 months
Example Packages: ???
Debian-Devel: Includes the collection of packages which are related to
software development. This would included compilers,
Release Freq: 3-6 months
Example Packages: gcc, g++, etc
Debian-HelixCode: Includes the Helixcode packages for the Debian
distribution
Release Freq: 3-6 months (or whatever is best)
Example Packages: all helixcode gnome packages
Now, about the coordination issue. Each release of a section would have
to be based on the most recent release of sections on which it depends.
The core sections would provide the basis for the other sections and,
therefore, each of the "other" sections would be developed alongside the
core sections. Whenever a new release of a core distribution was made,
other sections could then start developing against that release.
The core sections would have to coordinate releases a little more
carefully, to assure that everything worked alright. However, I believe
this could be done very effectively.
Oh well, tired of typing for now and I must get back to work.
Sincerely,
Paul J Thompson
--
To UNSUBSCRIBE, email to debian-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: