debian installer, install listofpackages.txt in CD root dir after end install?
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:
- zsh
- lilo instead of grub
- lukssetup (crypt thing)
- ext3 instead of ext4
- Xfree86 instead of Xorg
- systemX instead of systemY
etc. :-)
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 :
debian-simplified
debian-for-sysadms
debian-for-geeks
debian-for-lilousers
debian-for-sysV-users
and many more custom installers (custompackage lists in wikis)
On Thu, 13 Nov 2014, Russ Allbery wrote:
> Patrick Ouellette <pouelle@debian.org> writes:
>
> > 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
> > matter.
>
> > 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
> > Debian init system MUST provide" to allow it to declare Provides:
> > 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.
>
> --
> Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 87lhneeq53.fsf@hope.eyrie.org">https://lists.debian.org/[🔎] 87lhneeq53.fsf@hope.eyrie.org
>
Reply to: