Re: install report for Debian 2.1 and some comments on installation profiles
On Sun, May 09, 1999 at 04:08:34PM -0400, 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).
>
> 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/).
>
> 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.
>
> Voila. Elegant, uses the existing packaging system (i.e., no need to
> skip the select step in dselect),
This is the main point against your approach. We introduced the tasks and
profiles to avoid going through the list of 3000 packages in dselect. It
could be a nightmare to find those new metapackages in that huge list.
Don't get me wrong, I like the idea of using metapackages, but those
metapackages must be shown in a different level/screen on our package
selection tools (gnome-apt, dselect, whatever...). Until our tools are
modified to do that, I guess metapackages won't be that useful.
Another point against metapackages is that it's trivial for a new user
to make a new "task" (it's just a list of packages, one name on each
line) but it's not so easy to make a metapackage (it's a deb package,
with its changelog, control file, rules file and so on...). That may
probably be fixed by implementing a debhelper tool just for building
metapackages.
> 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.
Why wait? You can build that metapackage now, and we may use it as a
"test case" to see if any strange problem arises. A "gnome" metapackage
would be a nice one too. Volunteers?
--
Enrique Zanardi ezanardi@ull.es
Reply to: