[Exherbo-dev] Tags vs. categories

Bryan Østergaard bryan.ostergaard at gmail.com
Fri Jul 11 10:59:21 BST 2008


On Fri, Jul 11, 2008 at 8:22 AM, Jonathan Dehan <jdehan at gmail.com> wrote:
>
> Do you suspect there to be more than 100 providers per repository, or more
> than 100 exheres per provider? If you do decide to keep every minor version
> of a package and group things to broadly i guess the second is possible.
> Being more specific is better with providers though - http://pim.kde.org
> instead of http://kde.org etc. Still if it seems there will be a ton of
> exheres per provider per repository maybe adding yet another directory of
> just the package name
> ($packges/$repository/$provider/$package/$name-$version-$revision.$format .
> Otherwise that is a big hurdle to get around.
Providers looks a lot like categories and I don't really see any
reason to replace categories with something so similar.

>
>>
>> > For more in depth browsing, and not just tag searching, the tags can
>> > be exported as symlinks in
>> >
>> > $packagedir/tags/{$all-tags}/{$all-tags-plus-the-tag-selected-above}/{etc,etc}/name-provider-repository
>> > ->
>> >
>> >  $packagedir/packages/$repository/$provider/$name-$best_available_version_and_revision.$format
>> >
>> > Exporting all permutations of tags as symlinks on the filesystem
>> > makes it very flexible to browse for packages, at least until a
>> > proper interactive client comes around.
>>
>> That strikes me as a maintenance pain in the ass.
>>
>> --
>> Ciaran McCreesh
>
> I do not claim to know the amount of code that would be required to make a
> sync hook to add/remove new/dead exheres. A --regenerate-symtags could be
> difficult as well. A proper client to do realtime browsing would probably be
> better.
>
The symlinks could simply be generated server side and sync'ed by
clients. I think we should distinguish between browsing and searching
however.

For browsing categories already works fairly well - just like when
browsing through a book you need to know what you're looking for and
can find it quickly if you do. Searching is where you go for the
index.

As an example, lets assume that you need to read up on the '+'
operator in your favorite C++ book. Browsing, you would go directly to
the chapter on operators and then skim pages until you get to
operator+. For searching you would look up '+' in the index, then skim
related topics and find operator+ and the page(s) that's described on.

As tags can't be a replacement for categories (as discussed in
previous posts in this thread) I think we should concentrate on
building a better index and possible ideas for using tags beyond
searching or identifying packages.

>
> My brain is dying, heres a list of stuff:
> 1) Separate the unique identification of a package from other features (like
> the currently unusable way to browse packages).
Categories are quite usable imo.

>  solution: replace categories with providers
I don't see how providers actually fix any problems with categories.

> 2) Provide a simple tag based search mechanism.
>  solution: add TAGS="foo bar" to exheres and use inquisitio
>  requirement: choose format for TAGS
>  todo: implement it
This is easy as long as we decide that's all we're going to use tags for.

>
> 3) Provide a robust browsing mechanism.
>   solution a: live search of tags to pare down list in some client (probably
> graphical)
>   requirement a: must be fast
>   todo a: raise gtkpaludis back from the dead, or use packagekit :-p
I still don't know why you think the current browsing mechanism sucks
but I suspect you want to use browsing as a search mechanism which is
silly imo. They're two different methods for locating something and
they're both very useful imo.

>
>   solution b: export tags as filesystem symlinks
>   note b: this pretty much blows
I would block this tbh. The only thing we'd really get from that is a
huge mess of symlinks and complicating the sync process. Tags (without
symlinks) could already give you exactly what you're after using the
symlinks and an interactive client (like gtkpaludis) could present it
any way you like.

>
>   solution c: implement live search with inquisitio - thing tab completion
> that shows a list of more tags that would help pare down the search, plus a
> list of all the packages that match the current command.
>
That would be a feature for an interactive client.

>
> I think the first two items have good solutions, but the third is a bit
> tougher.
>
I think your solutions are trying to solve the wrong problem  :)

Regards,
Bryan Østergaard



More information about the Exherbo-dev mailing list