On 28/08/13 06:41 PM, ian_br...@fastmail.net wrote:
> On Wed, 28 Aug 2013 16:50:08 -0300
> Ben Armstrong <sy...@sanctuary.nslug.ns.ca> wrote:
>>> Alternatively, create a new pseudo-package called "task-live" which
>>> pulls them in, and have that included in the build via either
>>> "live.list.chroot" or "standard.list.chroot", which are in all the
>>> ISO build lists.
>>>
>>> What objection could there be to that?
>>
>> Why task-live? What makes these "live" things. I'm just not seeing it.
>
> Because one of the things that people very commonly want to do with a
> live ISO is access their existing filesystems, when they can't boot off
> them for some reason. LVM and RAID are not rare or unusual; they are
> standard for any serious installation.
If they are "standard for any serious installation", why aren't they
present if I do an install, accepting all default answers?
> If this usage is not contemplated, then why include the ext{2,3,4}
> utilities on the desktop ISOs?
You mean e2fsprogs which is "Essential: yes"? Please try a plain
debootstrap and see what happens. This was just a consequence of what is
installed in Debian by default.
> You'll say "that's what the rescue ISO is for."
Exactly.
> But then you have to use
> a text-mode console, which is really inconvenient if you need to look at
> a lot of things simultaneously, or refer to PDF or HTML (or online)
> documentation. It would be much better if basic mass-storage
> functionality was included in the desktop ISOs, as it very easily could
> be.
Aha. And now for the first time you state your real requirements.
> Which was my original point -- I thought we were just discussing what
> was the best way to accomplish it.
No, you have narrowly defined this as a problem with the prebuilt Debian
Live desktop images, and I have argued is a problem of understanding
where we draw the line with what gets included and what does not. It is
not done based on size considerations, or ease of including it, nor on
arguments as to the usefulness of each candidate package. I agree it's
not too big. I agree it's easy to include. I also agree it is useful.
Those are not sufficient criteria for these packages to be included.
So I'll recap and, I hope, sum up with a clarification of my point, as
you seem to have not gotten it:
The guiding principle for making each of the prebuilt desktop images is
that they should reflect what you would get by default performing a
Debian install and selecting each of those desktops. We prefer to
delegate the responsibility for package selection to each of the teams
who make it their specialty to say "this is what a default Debian
install for this desktop should look like". To that end, we make use of
task-* packages maintained by teams other than Debian Live to decide
what goes into those images. This frees us from the burden of
maintaining our own, possibly divergent lists of packages, preferring to
lean on the expertise of each group responsible for each task-* package
to make these decisions for us. It also gives users the freedom to use
those same package selections in other contexts that may not be live
systems, or may not be built using our own tools. It is simply a way of
saying "we focus on the live part of the problem, and the rest of Debian
takes care of the rest."
I acknowledge this does not cover all possible use cases, and your very
specific use case of "I want a desktop system that is also a rescue
system" is not addressed. To address it properly, we would need to make
each of the four desktop-flavoured variants of a rescue system, as
surely everyone desiring a desktop-based rescue image would want to have
it in their own favourite flavour. Logically, as well, we would need to
compound the historical mistake of maintaining our own package lists
within our rescue image configuration by extending it to cover "what are
the proper graphical rescue tools to include on each flavour of
desktop", as surely GNOME users will want GNOMEish rescue tools, KDE
users will want KDEish rescue tools, etc. I'm personally not interested
in such work ...
But this is surely a very interesting project for someone else to take
on. Personally, I find it not problematic at all to instead select one
of these three options:
1. Use my favourite prebuilt desktop image, boot it and install over the
network whatever tools suit the particular rescue operation I am trying
to perform.
2. Use the prebuilt rescue image and the command-line tools on it to do
my rescue operation.
3. Make a custom-built rescue image, perhaps starting with a clone of
the Debian Live project's rescue configuration with "lb config --config"
from the rescue image within the live-images git repo, then add my own
preferred desktop to it, and at my option, any "desktop-ish" rescue
tools suitable to that desktop. while i'm at it, since it is a personal
rescue image, I might include other things specific to my own
environment that I would find useful in case of an emergency.
This would seem to address adequately the particular use you see for a
live image. It's not a *bad* idea, per se. Just not one with an easy
solution that meshes with our project's goals that I think we want to solve.
Hope that helps. It is *my* opinion alone and should not be construed as
the "final word". Daniel has not chimed in yet. Nor do I expect him to
be available to do so for a few days yet, so perhaps he has some opinion
that would shed light on this. It would ultimately be his decision,
being the technical lead. I think we should just cool it until he is
available to give his 2c, as this conversation has so far not really
been that productive without his input.
Ben
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521e8078.8000...@sanctuary.nslug.ns.ca
