On Tue, Jun 26, 2001 at 12:54:24AM -0400, Joey Hess wrote:
> Hm, this is really your call as the maintainer of debootstrap, but an
> alternative way to look at is it debootstrap could just be responsible
> for installing enough packages to let base-config set up a full base
> system.
Hrm.
Well, as far as b-f/d-i is concerned, debootstrap has to set up a system
that:
(a) includes all of required (dpkg, ls, etc)
(b) can install more debs (apt, networking stuff (dhcp, ppp, pppoe?))
(c) can run base-config (adduser, tasksel, etc)
As far as, say, building a chroot for building debs is concerned, it has
to set up a system that:
(a) includes all of required
(b) can install more debs (apt)
(c) build-essential and dependencies
(d) any extra stuff as specified
I'd kind-of like to (eventually) simplify this a bit, so that b-f/d-i
can say:
"Yo, debootstrap, set me up a chroot with:
required
base
pcmcia-cs and ppp
"
and thus get as many of the exceptions gone as possible (required is
determinable from priorities; "base" could be section: base, or priority:
important, or something, hopefully; and b-f/d-i should know if the user
needs pcmcia-cs or ppp to do the install)
For comparison, to setup a chroot for building, you'd say;
"Yo, debootstrap, set me up a chroot with:
required
build-essential
netbase, libwrap-dev
"
> Haven't you already sort of given in the direction of base by
> special-casing in pcmcia-cs and ppp though?
Well, everything's special cased at the moment. That causes problems
when the special cases change (like groff -> groff-base). I certainly
can do special cases, I'd like to be able to get rid of them at some
point though.
> Or to look at it another
> way, if base is required + important + (special cases), it's not too bad
> to subtract out some other special cases.
Well, if the special cases are things like +ppp, +pppoe, that's fine because
it makes sense for debootstrap's caller to know about them, so I can hand
of the special casing to b-f/d-i at some point.
If it's a special case like -exim, though, I can't really do that. For
one, because it's not really any of b-f's business, and for two because
if we change that to postfix at some point (say), debootstrap or b-f's
breaks.
> But if you're dead set against this,
Nah, if exim shouldn't be in base, then it shouldn't be in base. If that
means I can't equate base with important, well, sucks to be me. I certainly
*can* just reintroduce the base section if I have to.
Would it make any sense to drop exim (and cron and at and mailx) from
important to standard? If you'd go "what the fuck?!" about them being
missing on a real system, does it make sense that you wouldn't go "what
the fuck?!" when you found they were missing from your new system after
you skipped both tasksel and dselect?
Oh. What do you think of giving people the option of pre-selecting all
of important, standard and/or optional as part of base-config, and then
possibly avoiding both tasksel and dselect? Selecting all of optional
won't work just yet, since there are still some conflicts and missing
deps in optional, but hopefully that'll be fixed soon.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpYikTgA9fMp.pgp
Description: PGP signature