[cut-team] CUT Implemented in 8 Lines of Shell

Michael Gilbert michael.s.gilbert at gmail.com
Fri Sep 17 18:12:04 UTC 2010


On Wed, 15 Sep 2010 08:02:48 +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 14 Sep 2010, Michael Gilbert wrote:
> > > What are you trying to prove?
> > 
> > I've demonstrated that a CUT implementation is possible using existing
> > infrastructure.  No proofs, lets leave that to the mathematicians :)
> 
> Sorry if I have been somewhat harsh in my first reply but I really had the
> impression that you wanted to prove that the current implementation plan
> of CUT is overkill and not needed.

My opinions are that creating new snapshot archives to support
installation of testing snapshots is redundant/unnecessary, and that
snapshotting testing doesn't actually solve any of the core problems
in the CUT manifesto.

> And your proposal is really only a hack IMO:
> - snapshot.d.o is not meant to be used by lots of end users at the same
>   time, it has no mirror network and really can't due to the completely
>   insane size it takes over time

That's simply a technical limitation of the existing snapshot.d.o.
6.5 terabytes isn't that insanely large nowadays, and the size of the
current testing archives is probably more like 500 gigabytes.  Hard
drives of that size only cost around $50 nowadays, but getting a 2
terabyte drive for $200 instead wouldn't be a bad idea/investment.
Ultimately snapshot.d.o can be mirrored, it just currently isn't.  That
can certainly be fixed.

> - snapshot.d.o is read-only, we can't add/remove/modify packages in a
>   given snapshot

Why would you want to do this?  The snapshot should be chosen because
it is in a good shape, not because certain packages have been forced in
without going through standard testing processes.

> > Users that like new/experimental features can always attempt an install
> > with the in-development testing d-i.  My approach makes no effort to
> > address prevent them from doing that.
> 
> CUT wants to bring the latest working feature to all users. Advanced or
> not.

Why is bringing all of the latest features necessarily a requirement?
And where is that stated?  It's certainly not in the manifesto.

Advanced users can get around installer limitations anyway.  Taking your
brtfs issue as an example, once the user has the new kernel, they can
boot into single user mode, unmount the root partition, and use
"btrfs-convert" on their partition.

Best wishes,
Mike



More information about the cut-team mailing list