a lot of these problems will be solved in the new distributionless system
that is being worked on.. allowing for many more brances of subsets of
software, such as being able to use the latest and greatest PHP/apache,
without having to jump full force into unstable.  multiple versions of
packages will be stored in the same directory structure on the main debian
tree, the tree will be huge, but can be parsed down to a more useable form
by simply compiling a Packages.gz and buliding an ISO.. (which i'm going
to do with a package.list tonight, using utilities on the
cdimage.debian.org site)

Thank You,
        Ben Kochie (ben at nerp.net)

*-----------------------*  [ - * - * - * - * - * - * - * - ]
| Unix/Linux Consulting |  [ Haiku Error Message:          ]
|  PC/Mac Repair        |  [  Chaos reigns within.         ]
|   Networking          |  [  Reflect, repent, and reboot. ]
| http://nerp.net       |  [  Order shall return.          ]
*-----------------------*  [ - * - * - * - * - * - * - * - ]

 "Unix is user friendly, Its just picky about its friends."

On Wed, 28 Jun 2000, ^chewie wrote:

> 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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org
For additional commands, e-mail: tclug-list-help at mn-linux.org