It would be very cool if the debian installer had a listofpackages.txt
and that listofpackages.txt could be edited by the user
then we would be getting customized debian installs
some people would edit and tell it to auto install:
- lilo instead of grub
- lukssetup (crypt thing)
- ext3 instead of ext4
- Xfree86 instead of Xorg
- systemX instead of systemY
would be very cool if this was possible
it is hard to do everyone right in the installer
so most people will have to install afterwards
but not if this was possible
they could make their own perfect debian install cd
would be a sysadm's dream..
also the geeks dream
of course there is debootstrap too, but it would be cool if the debian installer could be made like this too
just dragdrop a list of installpackages.txt into base of debian install CD
then the CD finds that list and replaces grub with lilo in end of install if needed
and sysX with sysY if specificed in list
would be the ultimate customization, we would get wikis filled with packagelists for custom debian cds
the biggest problem is we would get nonsupported debian dists, could be a big problem
people claiming they use official debian, but then own packages in installer
still think it would be very cool... debootstrap can provide this, but debian installer can't do this easily
only if you are a debian programmer do you know how to do it probably...
until then I prefer to use debootstrap, I don't like to use the installer because it forces me to use certain packages
i.e. it installs grub and newest kernel for me, which I might not want
or it installs sysX instead of SysY
I know I am picky... and lazy
I do really like the ssh connection to the installer though....
this is just a last suggestion, would make perfect debian installers if this was possible
override all packages after end install if custompackages.txt exists in CD directory
of if it exists on a usbstick on the pc that gets automounted
unlimited configuration possibilities!
I could tell it to install an old kernel, a custom compiled kernel etc.
I often use custom kernels... would have to install those manually after installing as it is now
many sysadms use custom kernels they have compiled for debian themselves
as it is now they have to debootstrap or install normal debian dist
then copy it over afterwards
with this im suggesting they could make their own debian installer with their custom kernel on
custom bootloader etc.
custom kernel is ALSO just a simple .deb package to install!
lilo bootloader is too
so that listofpackages.txt should just contain .deb filenames to install after end of installation!
would be very unique to the debian installer if this was possible
all people would stop complaining, almost ;)
we would be getting :
and many more custom installers (custompackage lists in wikis)
Post by Russ Allbery
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
The current systemd / GR issue would not be happening if the project had
not said the default init system shall be <init system>. Had the
project said we have the following init systems available: <list of init
systems> and let the other package dependencies drive the user's
selection then users would fell there was a little more choice in the
Right now, GNOME seems to be the primary driver for requiring systemd.
If you don't use a graphical environment, you don't need systemd but you
are forced to at least install it on a new build.
Various people were discussing the installer experience elsewhere, and
whether enough users care about this to warrant making a sysvinit install
an option directly in the installer. I don't think this is any sort of
fudamental decision we've already made; it's a debate over UI experiences.
In other words, I don't think this is anywhere near as central to the
argument as you seem to think. If I'm wrong, that's great news -- if all
of this argument could go away by just tweaking the installer UI, that
would be fantastic. But I'm dubious.
If there are two opposing sides, then there are two maintainers willing
to maintain the packages. If there are not, the package without a
maintainer looses by default.
Ah, see, I also believe this, which is exactly why I'm so upset about the
current GR. The proposed GR (the first option) is exactly about
overriding the normal practice that the package without a maintainer loses
by default, and about *forcing* the people who aren't using sysvinit to
work on maintaining it. This is one of the fundamental divisions in the
project right now.
Of course, proponents of it probably even disagrees with my
characterization of it, because we're *also* fundamentally disagreeing
over even what the proposed GR actually does.
It really is deep disagreements all the way down.
I don't recall Debian every saying we will support package <package>
forever and ever.
Exactly, and that's why some of us are aghast at a GR that basically says
that about sysvinit, except cast in terms to try to make it seem like
that's not what it actually says.
Waiting implies lack of movement - this is not what I was saying. I say
allow the natural evolution to play out. GNOME wants to require systemd
and someone packages systemd - great - allow it AS AN OPTION, NOT A
REQUIREMENT for all. Similarly with sysvinit - it has maintainers,
allow it as an option.
This means that you and I are basically in agreement, and I suspect you'll
find that you're basically in agreement with most of the people on the
systemd "side." That's pretty much the position that I've been arguing,
and the position that I believe the current GR is trying to reverse by
forcing GNOME, and every other package in Debian, to support sysvinit.
The only remaining thing about which we may disagree is that I think the
installer needs to pick *something* that gets installed by default, and
that the average user isn't going to care or know enough to pick
something. (I would like to see the inability to select sysvinit via such
install methods as debootstrap fixed before the release; I think that's
just a bug.)
The issue we should be tackling is not which init system to force on the
users, but the higher level "what is the minimum functionality and API a
init-system in its control file.
That sounds like a great discussion to have, from my perspective, and the
discussion that I was hoping we could have following the TC (and that I
was then unable to try to drive due to a lot of non-Debian life stuff on
my part). But I don't think that's the discussion that the GR is having,
or that most of the systemd arguments are focused on.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org