Profile packages (was super packages)
On Wed, Sep 30, 1998 at 11:26:01AM +0200, Christian Meder wrote:
> I'm the guy who did the package selection for the profiles and tasks
I like your suggested name of profile packages. Can we all live with
that name?
> of the preselection stuff in our installation. No doubt it's a quick hack.
> I consider empty dependency packages like proposed to be a better solution
> and we should try it. If David agrees I will upload one or two test profile
> packages with the data taken from my preselection work.
Excellent! Please go ahead. Besides the preselection you have,
another good candidate for a profile package is gnome. With the
fluidity of the gnome packages (no offense to Jim Pick), it would be
nice to just select a single gnome-environment package and get a good,
basic, but complete, installation of gnome.
> * we shouldn't push this kind of change in slink before we tested
> and approved it
Agreed, but if we can show that it is worthwhile and can be done
without delaying slink, then it should be included.
> * it's still a different approach compared to the preselection step in the
> installation process. If someone selects a profile package he will be thrown
> in the dependency resolution screen of dselect, a step which we wanted to
> avoid in the preselection phase. Preselection shouldn't use the Select step
> of dselect at all. Things will certainly improve when we can rely on apt
> being present.
I don't understand this. If the preselections or profile packages are
done reasonably, there shouldn't be anything that needs to be resolved
on an initial installation, right?
> * recursive removal shouldn't be a part of the profile packages, it should be
> handled by apt.
Agreed again, but I suspect something might need to be done with
dselect before apt is ready.
On Wed, Sep 30, 1998 at 12:02:49PM +0200, Federico Di Gregorio wrote:
> Mmmhhh. Yes. Just a comment: all the friends of mine that installed hamm
> and used the preselections complained that toooo much stuff was installed
> in their boxes. Maybe more "granularity" would be better... (100 selections
> of 10 packages each and not 10 of 100 packages...)
FYI, the shear number and granularity of current Debian package is one
of the main reasons I proposed the profile package idea. My feeling
is that profile packages should represent robust, but not kitchen
sinkish, collections of packages and that there shouldn't be a
tremendous number of profile packages. My gut feeling is that there
should be about 40-50 profile packages. Any more than that and I
think we will the mark on usefulness.
On Tue, Sep 29, 1998 at 10:26:27PM -0400, Michael Stone wrote:
> I think this needs to be handled pretty carefully; I can envision a
> situation where a user might get used to using a program that belongs to
> a superpackage, without knowing its relation to the superpackage. When
> he goes to clean up, he might get a nasty surprise. I think the idea of
> automatically removing children (for lack of a better term) is too
> risky.
This is why I try to be careful and say SEMI-automatic removal.
On Wed, Sep 30, 1998 at 03:49:31AM -0400, Branden Robinson wrote:
> On Tue, Sep 29, 1998 at 09:20:06PM -0500, David Engel wrote:
> > I suggest the maitainer of the core packages that comprise a super
> > package maintain the super package as well. For example, the libc
> > maintainer could maintain a c-developement super package and the X
> > maintainer could maintain x-workstation and x-development super
> > packages.
>
> Sure, put more on my plate. :)
Alright! Did you hear that Christian?
> > I think a section makes the most sense. BTW, does anyone have a
> > better name than super packages?
>
> Überpackages!
Too late. I like profile packages better. :)
David
--
David Engel
dlengel@home.com
Reply to: