Re: package sections (2K packages problem)
On Sat, Jul 24, 1999 at 01:19:42AM +0200, joost witteveen wrote:
> Je 1999/07/23(5)/23:07, Wichert Akkerman montris sian geniecon skribante:
>
> [2K packages problem: more more sections, hierarchical sections, etc]
>
> > There have been proposals of using keywords to make it easy to search
> > for packages, and people suggesting that we make the sections more
> > hierarchical and add subsections.
> >
> > However with the new menu-system as introduced by Joost I was wondering
> > if we could use his dynamic menu system for packages as well? We could
> > use our existing sections, perhaps add a second hierarchy level and use
> > keywords in the same way the menu system uses hints?
>
> <cut: hints and menu system>
>
> However, the hints code is written now, and it could well be used
> to setup directories populated with symlinks to the `real, static, current'
> directories. For those symlink-populated directories we could
> indeed set some desired number of directory entries, and regenerate the
> whole structure every time dinstall is ran.
In the past, we've always had the dselect hierarchy mimic the ftp directory
hierarchy. Is there any reason for this to be the case? Why bother with
symlinks? Why not leave the ftp site alone? The need to be able to sort
through things by hand is no longer needed much with apt-get doing everything
for you, and if you _do_ need to manually download something, the current
directories are sufficient.
Instead of forcing this unnatural mirroring of the conceptual hieararchy
dselect/future apt tools in the physical arrangement of the ftp site, the
two should be divorced altogether. The ftp site can continue as it does
now -- it's quite sufficient for the purposes it serves, and changing it
would be nasty for the mirrors, as you mention. The conceptual hierarchy
can be specified either in a separate file, most likely fetched by apt
(this would favor backwards compatability, as well as the ability to try
out different ways of arranging things, and could even be implemented as
as debian-hierarchy package), or by adding additional fields to the package
control file.
Furthermore, by making such a change, it frees us from the strict
hierarchical arrangement imposed by the filesystem and allows us to play
with other, perhaps better arrangements. For example, the keywords
mentioned, or a system which allows us to change how the package tree
is represented based on what we want (for instance, the original message
outlined a task based hierarchy with net/mail/ containing all mail
related packages, and with mtas or servers as a subcategory -- but wouldn't
a sysadmin setting up a server find it more useful to have a net/servers
category containing mail, http, etc. as subcategories?); I especially think
that packages should be able to appear in different categories at the
same time -- emacs comes to mind as the canonical example of this, but
it applies to other programs as well. For example, shouldn't gnome-icu
be in both net/messaging/icq and X/gnome/panel-applets? (One advantage
of having the hierarchy in a separate file and not specified by the
individual packages is that it allows us to play with all these options.)
Decoupling the dselect hierarchy of packages from the ftp filesystem
hierarchy makes all sorts of nifty things happen.
> Naturally this will cause many people to complain about the package
> hierarchy not being static any more -- but those people can always
> use the old, non-symlink, real structure. (Just like those people can
> use the old menu tree in menu).
> Probably there are two different types of users (with some overlap):
> those who `know' the debian package directories, and those who don't.
> Those who know the structure, should use the old directories, those
> who don't know the structure are the ones that complain about the hugeness
> of the directories, and they can go on looking in the `user-friendly'
> symlink directories. Or, even setup their own personal symlink-directory
> if they've got a full mirror/CD.
>
>
> (Probably the directory structure of where the actual files
> reside should be as static as possible, for the mirrors etc).
Yes; my proposal achieves all these goals just as well, and better in some
cases.
-- Nathaniel
Reply to: