[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is this really the right thing to do?



Helge Hafting wrote:
> 
> > > The problem of needing *some* sort of terminal can be solved by having
> > > both xterm and rxvt provide the same "terminal" capability, and have
> > > x-base suggest the "terminal" stuff.  It shouldn't depend on it though,
> > > one can imagine an useful x-installation without a terminal.
> >
> >
> >       Nothing wrong with what you say above.  The problem is, you and I know
> > what xterm and rxvt are.  We don't need to be told they are related to
> > X11, or that at least one of them is really needed to use X11.  A user
> > unfamiliar with X11, will, in dselect's select display for the section
> > X11, see a huge list of alphabetically sorted files where most start
> > with 'x' in the name.  'rxvt' will be toward the middle of the list and
> > 'xterm' will be towards the end.  The rest of the X11 debs will be
> > interspersed with other packages that start with 'x'.
> 
> The unfamiliar user may try to install xbase, as the name suggest that
> you really ned that one.  With my "suggest" idea, dselect will then
> pop up a warning saying "xbase suggest x-term-emulator, xterm provides
> x-term-emulator, rxvt provides x-term-emulator, nnn provides ...
> This system is in use for mail software already, and don't require
> namechanges.  (Try installing smail, dselect will suggest a bunch
> of mail readers to go with it if you have none.)


	This is already done by dselect in the conflicts screen.  You can
scroll the line down and see the 'suggestions' given in the lower screen
by the package that makes the suggestion.  I guess what I'm really
saying is that there needs to be a visual clue that explains the
relationships between packages. Example:

   X11 -   xbase
       |
       -   xfonts-xxx
       |
       -   rxvt
       |
       -   xterm


> 
> >       Maybe a policy of a common prefix would be sufficient.  Would having
> > xterm and rxvt change their package names to 'X11-xterm' and 'X11-rxvt',
> > be ok?  Or should dpkg/apt be modified to understand the concept of deb
>
> I don't know if prefixing everything with X11 would make it better,
> you would basically get exactly the same list in the same order,
> with X11 in front of everything?


	I'm not to keen on this myself, but it would at least get all the core
X11 system packages in one place in the select screen.  Right now the
X11 core packages (xbase,xfonts,xserver,xterm,xf86config,etc) are
intermingled with all the other X application programs.  The version
number does provide a clue that they are related and are part of a
package group.


> 
> > package 'groups'?  Imagine a 'group' display in dselect of the X11
> > section, which not only lists xterm and rxvt together, but also shows
> > they are components of the X11 software system (X11 apps would show up
> > individually, or in their own 'group' if necessary).
>
> When I run dselect, the x11 stuff is grouped already.  Having these groups
> collapsable (and having sub-groups) like "make menuconfig" would
> improve it further.


	The X11 section just groups all X11 core packages together with all the
available X apps in alphabetical order.  It doesn't distinguish between
the core packages of X11 (part of a large deb 'group') and all the
available X apps.  A sub-grouping mechanism would help as you said.


> Another thing I would like to see would be some default suggestions.
> I.e. an entry for "standard X11 installation on workstation" that
> autoselects xbase, xterm and a bunch of other things you usually need.
> Similiar to the first-time installation thing, but integrated into
> dselect or whatever replaces dselect.


	I agree.

 
> A user with little knowledge could then select entries like
> "standard x11 on workstation" or "x-terminal only",
> "email using pop3/smtp", "email using smtp only"
> "development system with gcc" and so on.


	Yes.


> Using these entries would save time for smart users too.  Selecting a
> "standard package" of packages would simply turn on a predefines set
> of packages, and the smart user could review that instead of
> searching for the 15 packages he know he need.
> 


	Kind of a 'MetaPackage', a package of packages.

	Lets not, though, lose the distinction between what I'm talking about
and what your saying.  I'm concerned about large software systems (with
many libs and binaries) like X and GNOME, that come in multiple deb
packages from being lost in the larger alphabetical ordering of a
section in a dselect selection screen.
	You are talking about a higher level association of packages that are
not explicitly related to one another as being part of a software
system.  Instead the relationship is defined by the users.  Your example
of 'email using pop3'  could associate the exim deb with the fetchmail
deb, while 'email using smtp only' would leave out fetchmail (or
something like that).


> Helge Hafting

-- 
Ed C.


Reply to: