Re: install report for Debian 2.1 and some comments on installation profiles
On 9 May 1999, Adam Di Carlo wrote:
> [Talking about tasks and profile from boot-floppies]
>
> >>>>> "brandon" == Brandon Mitchell <bmitch@atdot.org> writes:
> brandon> I'd personally like to see a way to easily add a profile via
> brandon> dpkg -get-selections and make for a cookie cutter install
> brandon> (think large labs).
[ woah, this is an old thread, but a good one to bring back. ]
> Eh... I don't see this as a good idea. I personally would rather see
> all the "tasks" made into "metapackages" (packages which are basically
> just a bunch of dependancies, and some info in /usr/doc/).
Ok, my first reaction is that this is a quick and easy hack with a better
solution that we are missing. I can't convince myself of that the more I
think of it. These tasks need to be tightly integrated with the packages
and some how compatable with what we have. Unless someone has a better
idea, abusing the packaging system seeems to be the best solution.
> Then you can maintain your tasks and profiles all the time.
>
> Also, tasks would be task-<taskname> metapackages, depending on actual
> Debian packages. Profiles would be profile-<profilename>
> metapacakges, depend on just the tasks.
I'd also propose a new section for tasks, so that they are easy for users
to find and for the package installer to separate out if necessary.
> Voila. Elegant, uses the existing packaging system (i.e., no need to
> skip the select step in dselect), simple, and, really, it has little
> to do with the boot-floppies at all. Although, the existing GUI could
> be changed a bit so it just installs these metapackages, rather than
> the actual packages themselves. Furthermore, users who are upgrading
> or whatever can take advantage of tasks and profiles, rather than just
> those who are using the boot-floppies.
Yes, the next frontend to apt (gnome-apt?) should handle the tasks
specially. They should be able to hit a customize button for each task
which can take you to a dependency resolution screen. This way if the
task depends on a web server or apache, it defaults to apache, and the
customize screen for that task will show all web servers. Then provide
another customize button to handle all packages (what we have now).
> Another nice benefit to my scheme is that each task/profile can be
> maintained independantly by different Debian developers. In fact, I
> volunteer to take over the SGML environment task if we do move to this
> scheme.
Agreed, distributing the work into small chuncks is better and one reason
debian has done so well.
> So -- lets have a little discussion period, and then decide, and
> perhaps start looking for volunteers. We need to jump on this quick
> so we can have it in place for freeze time, whenever that is.
It probably isn't difficult to convert the old tasks into packages and put
them up on an apt-able site. Then those who want to test can go right
ahead. It's about time I became a maintainer so I can put my package
where my mouth is. Graduation and a move are soon, I'll start after
that's over.
Brandon
+--- ---+
| Brandon Mitchell bmitch@atdot.org http://bmitch.dhis.org/ ICQ 30631197 |
| Throughout history, UNIX systems have regularly been broken into, beaten, |
| brutalized, corrupted, commandeered, compromised, and illegally fscked. |
| -- UNIX System Administration Handbook |
Reply to: