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

Re: Sections



I demand that Drew Scott Daniels may or may not have written...

> On 07 Apr 2003 07:51:43 +0200, Thomas Hood wrote:
>> On Sun, 2003-04-06 at 20:37, Mark Howard wrote:
>>>   Reading the discussions based on bug #187245, it seems that most people
>>> agree that package sections are fairly useless. Freshmeat style trove
>>> categorisation is quite an interesting idea, but it would then make it
>>> quite difficult to produce tools like aptitude which could potentially
>>> list all possible packages in a tree - there would be too much
>>> duplication.

> But it wouldn't hurt to have it as an option for people who are only
> looking at s few small sections.

>> Why is this a problem?  Packages have various characteristics and so can
>> appear at various location in the listing.

> A good example of his idea is dmoz.org's subdirectories. I see it as a
> potential problem to people who are looking at all of the sections and see
> the same package listed many times and waste too much time looking at
> things they already looked at. Another way to solve this is however some
> way to set "I don't want this package so don't show it in other sections"
> [...]

I've not written code for the following (and probably won't); it's just here
for comment.

* Automatic hiding.

  Once a package is shown, automatically flag it as "shown in $SECTION" and
  don't show it in other sections. Allow the user to clear these flags;
  automatically discard them on exit.

* Highlight or unhighlight by keyword.
* Show or hide by keyword.

  Fairly simple commands (at least, simple to use)- I hope. Implementation
  should use either some set of prefixes which allow combinations of
  with/without any/all ("highlight games +gtk +console !gnome"), or Boolean
  expressions ("highlight games and (gtk or console) and not gnome").

  Highlighting could use a simple scoring system. This could be good for
  specifying multiple highlight/unhighlight rules in order to try to keep the
  view more easily readable and editable.

* Sort by keyword.

  This would take a list of keywords and sort the package list according to
  this, with unlisted keywords following in locale order.

  A special token to place otherwise-unlisted keywords somewhere else in the
  list would also be useful on occasion: packages which have keywords which
  are listed after this would be sorted separately and be listed last. This
  is saying "I don't really want this type of package, but if it's all that's
  packaged..."

Being able to store these as labelled "package views" and, perhaps, to ship
some preconfigured views, e.g. for GNOME packages, KDE packages, and other
X-dependent packages, I think will be found to be useful. Quite probably also
being able to overlay one package view on another: that way, given a scoring
system for highlighting, there could be a view (applied last by default)
which negatively scores contrib and non-free ;-)

Incidentally, using the components of the section name as keywords would be
good: all packages will automatically have at least one keyword.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| Debian woody, | youmustbejoking  | Northumberland
| RISC OS       | demon co uk      | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Invention: the solar-powered torch.



Reply to: