Re: install report for Debian 2.1 and some comments on installation profiles
Enrique Zanardi <ezanardi@ull.es> writes:
> > 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.
You misunderstand. You could still have the *identical* metapackage
selection interface presented to the user as we currently have.
However, it would simply mark the metapacakges for installation,
rather than a ton of "atomic" (i.e., normal packages).
The select step could be either skipped or not skipped.
Any good package installation method (um, well, only apt is this good
I guess) would automatically pull in dependancies.
So I guess a weakness of my scheme is that it presupposes apt and only
apt. Or else the user needs to go through the "[S]elect" step.
> 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.
There's no reason this could not be adopted to metapackages, where it
now uses, ahem, "proprietary" text files.
> 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)
I would hardly call that trivial. They might as well just go into
dselect and pick out the pkgs they want. Moreover (and this is the
primary weakness), the current system completely ignores internal
archive dependancies, i.e., those have to be manually satisfied by the
tasks.
> 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.
Well, as someone pointed out, equivs fulfills this function.
> > 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?
Ugh, I guess I volunteered myself. Well, not biggie -- I've been
maintaining an sgml metapackage internally for onShore for months now.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: