Re: Disabling recommends - was [Re: bash-completion pros/cons]
On Fri 19 Jun 2020 at 06:23:00 (-0500), Richard Owlett wrote:
> On 06/18/2020 10:25 PM, Andrei POPESCU wrote:
> > On Mi, 17 iun 20, 06:51:18, Richard Owlett wrote:
> > >
> > > The purpose is to determine if I want to do future installs debootstrap.
> > > I attempted to use debootstrap a few years ago and understand it will take
> > > some time/effort to learn it.
> >
> > If you are going to start from scratch you should consider mmdebstrap
> > instead (preferably the version in bullseye). It is mostly a drop-in
> > replacement for deboostrap, but significantly faster and with some very
> > useful additional features.
>
> IIRC I had looked at it when experimenting with debootstrap and was
> confused by its use of chroot. My goal was creating a bootable system
> on a flash drive.
> >
> > As to the learning curve, deboostrap itself is quite easy. The hard part
> > is getting a usable system *after* the deboostrap step.
> >
> > At that point one gets to really appreciate the hard work that went
> > behind debian-installer ;)
>
> You are "preaching to the choir" ;/
>
> That why I'm investigating making the installer do what I want.
>
> In a way, my underlying problem is Debian has done too good a job
> in creating a system maximally useful to the broadest spectrum of
> users. They don't use my preferred programs for some functions and
> including functions I have no interest in. That results in unnecessary
> clutter and size.
I couldn't agree less; I think you're starting at the wrong end.
There's plenty of evidence in the lists that you have run the d-i
countless times, yet I haven't seen any evidence that you've tried
to analyse how it works by, say, reading the source, notwithstanding
the fact that you play your cards close to your chest.
In choosing to work on "taming" the d-i, you've chosen a piece of
software that, by its very nature, is obscure in how it works.
It's even composed of packages that differ from their "grown-up"
cousins in the final OS installation, limiting the transfer of
knowledge.
A Debian installation is loaded up with any number of introspective
tools for examining its own composition and behaviour. None of that
is available to you while the d-i is running. Just crudely trying
to understand what it did after the event involves merging its log,
apt's history, and the screens displayed by its front-end (if you
remembered to record their timings). And even that casts little
light on the debootstrap stage. Looking at its log, you can see
that, for much of the time, the system is in a semi-broken state,
ignoring its own dependency and configuration problems. Is that
really what you want to work on?
Why not start with a minimal working system, even adding a few
select tools, and then see what isn't necessary for your own
minimalist system. Now you can try removing them from a *working*
system and, should you go too far, you still have the tools to
diagnose what's gone wrong, and fix it.
That way, you end up having constructed a post-installation script
that, instead of installing nearly 300 packages and purging two
like mine, will purge a modest number of packages and install
very few.
One other benefit: the knowledge and skills you gain in this process
will be far more transferable than a deeper understanding of the d-i.
After all, I haven't gained the impression that you're in technical
charge of rolling out, say, 5000 installations of Debian across
some institution or other.
Cheers,
David.
Reply to: