[Exherbo-dev] Tags vs. categories

Jonathan Dehan jdehan at gmail.com
Fri Jul 11 16:46:56 BST 2008


On Fri, Jul 11, 2008 at 5:59 AM, Bryan Østergaard <
bryan.ostergaard at gmail.com> wrote:

> 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.
>

Provders as I proposed it is not meant to replace categories in effect, just
on disk.


> >
> >>
> >> > 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)


Guess I missed that, which changes things. All my ideas were with that in
mind, and I guess I will have to re-read carefully as to why that is.


> I think we should concentrate on
> building a better index and possible ideas for using tags beyond
> searching or identifying packages.
>

The only thing I can think of for tags, beyond searching and browsing
packages, is as a replacement for virtual dependencies. It just seems like
generic metadata, which when applied for a specific purpose is no better
than just adding a new field, like PROVIDES="sdk: java" or what have you. Or
if its meant to inform the user its like a limited version of annotations.
Maybe I am not thinking on the right level.


>
> >
> > 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.
>

They are moderately usuable, when you know what package you are looking for
mostly. When you are browsing available packages, the ability to pare down
an arbitrary amount until the list is parsable I think is far more valuable.


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

It doesn't - providers fix the uniquely identify packages problems, and the
problems with categories is fixed by tags in this proposition.


>
> > 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.
>

Agreed.


>
> >
> > 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.
>

I guess I am proposing that tags be used as sort of a hybrid of the two -
you know you want a game. So you inquisitio --tags game and see there are a
ton of games. Then you decide you want an rpg, so you do inquisitio --tags
game rpg and see there are still a ton of rpg games. To make the list
easier, you see what kind of online rpg games are out there and do
inquisitio --tags game rpg online. Now the list is down to a managable
amount and you can query thier descriptions and maybe go to the homepages to
learn more about them. Its for when you kinda know what you want but really
just want to see whats available. This could be implemented with categories,
but might require multi-depth categories and at that point you want symlinks
incase you were thinking 'I want an online game'. Unless you enforce an
arbitrary rule like 'categories must be in alphabetical order drilling
down'. It just gets messy at that point and I don't see a way around it
unless a good interactive client is developed. If this is the case, then
yeah exporting tags as symlinks is silly. Still, it would free up the
directory tree to be whatever.


>
> >
> >   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.
>

Yeah a good interactive client would be awesome.


>
> >
> >   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.
>

And if an interactive client was made, who would use on disk categories to
browse?


>
> >
> > 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
>

I tend to miss the mark a lot, thanks for helping clear things up a bit.

Tags + good interactive client would be the best fix for browsing,
inquisitio + tag support would be fine for searching. I would love to hear
ideas for what tags could also be used for. If a good interactive client is
developed then I see no need to keep categories as they are, and no need to
replace them unless there is a conflict where the same named package is in
the same category. In that case I would just make a new category for that
particular package. The categories at that point should be as clean and
consistent as possible for developer sanity only. They shouldn't be
repurposed as usable metadata either - all metadata should just be in the
exheres. I don't know how a package manager is coded so if there is huge
issues with this, I am sure it will be pointed out.


Thanks,
Jonathan Dehan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20080711/f46aede7/attachment-0001.htm>


More information about the Exherbo-dev mailing list