I may send this on to debian-devel, but I haven't decided yet.  I want
to browse their archive first...

Everyone here knows me to be as big of a Debian advocate as the next
guy, but I've certainly got problems with the way they handle their
distribution.

My bigest pet-peeve with Debian is it's policy for package QA (or lack
thereof) and it's focus on the unscaleable schema of a "distribution
release".  Don't get me wrong, I like the assurance of stable packages
in the "stable" distribution, the committment to fixing bugs in the
"frozen" distribution, and the availablity of bleeding edge in the
"unstable" distribution, but I think the number and available of
packages/software has outgrown this schema entirely.

What is needed, IMHO, is...

    1.  A way to retrieve any version of a binary package at any time.

    2a. A way to tag a specific version of a package based on it's lifecycle.
        (i.e. DEV, TEST, PROD, MAINT, DEFUNCT)

    2b. A way to tag a version of a package based on the lifecycle of
        the actual program it contains.

    3.  A way to grade a package based on it's stability or lack of bugs

    4.  A way to install, upgrade, or remove versioned packages based
        on the values found in 2 and 3.

    5.  A way to consult the "popularity contest" scores of the package
        during the installation process.

Advantages to this scheme...

    1.  Distribution "releases" would no longer need to be based on
        arbitrary decisions of which packages are "stable" and which
        are "buggy."

    2.  Releases (package installation lists) could be selectively
        built on the lifecycle tags of the packages or the software
        itself.  
        
        For example, we could select all of the packages tagged as
        PROD/MAINT quality for software that is either in it's
        PROD/MAINT lifecycle.

        A more specific example would be to build a database server
        with the most recent PROD level package of PostgreSQL in its
        PROD or MAINT lifecycle.  The dependency tree structure would
        allow us to cascade from this top-level selection down through
        the required packages for a minimalistic server install.

    3.  Tighter Quality Assurance could be maintained through this
        tagging scheme, as policies for tag promotion could be set and
        enforced.

    4.  Historical versions of the software package could be retrieved
        at any time.  Increasing flexibility in recovery schemes or
        "oops" scenarios.

Problems with this scheme, as I see them right now...

    1.  Saving each version of a binary and source package puts the
        crunch on disk-space and archive size.

    2.  AFAIK, there is yet to be a stable, useable tool for
        versioning and storing binary packages as "diffs" to cut
        down on the size required.

    3. Of course, new tools would need to be built... (duh)

If there were ever to be a revolutionary change to how OS's are
installed and maintained, this would be it.  Coupling the ease of use
that 'apt' has given us with the quality control and flexibility that
the above scheme would allow us, we could pound the market with job
and quality specific installations of Debian Linux.

-- 
Chad "^chewie" Walstrom <chewie at wookimus.net>
        http://wookimus.net/chewie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 242 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20000628/af04df61/attachment.pgp
-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org
For additional commands, e-mail: tclug-list-help at mn-linux.org