On Fri, Jul 11, 2008 at 5:59 AM, Bryan Østergaard &lt;<a href="mailto:bryan.ostergaard@gmail.com">bryan.ostergaard@gmail.com</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Jul 11, 2008 at 8:22 AM, Jonathan Dehan &lt;<a href="mailto:jdehan@gmail.com">jdehan@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Do you suspect there to be more than 100 providers per repository, or more<br>
&gt; than 100 exheres per provider? If you do decide to keep every minor version<br>
&gt; of a package and group things to broadly i guess the second is possible.<br>
&gt; Being more specific is better with providers though - <a href="http://pim.kde.org" target="_blank">http://pim.kde.org</a><br>
&gt; instead of <a href="http://kde.org" target="_blank">http://kde.org</a> etc. Still if it seems there will be a ton of<br>
&gt; exheres per provider per repository maybe adding yet another directory of<br>
&gt; just the package name<br>
&gt; ($packges/$repository/$provider/$package/$name-$version-$revision.$format .<br>
&gt; Otherwise that is a big hurdle to get around.<br>
</div>Providers looks a lot like categories and I don&#39;t really see any<br>
reason to replace categories with something so similar.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Provders as I proposed it is not meant to replace categories in effect, just on disk.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; For more in depth browsing, and not just tag searching, the tags can<br>
&gt;&gt; &gt; be exported as symlinks in<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; $packagedir/tags/{$all-tags}/{$all-tags-plus-the-tag-selected-above}/{etc,etc}/name-provider-repository<br>
&gt;&gt; &gt; -&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &nbsp;$packagedir/packages/$repository/$provider/$name-$best_available_version_and_revision.$format<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Exporting all permutations of tags as symlinks on the filesystem<br>
&gt;&gt; &gt; makes it very flexible to browse for packages, at least until a<br>
&gt;&gt; &gt; proper interactive client comes around.<br>
&gt;&gt;<br>
&gt;&gt; That strikes me as a maintenance pain in the ass.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Ciaran McCreesh<br>
&gt;<br>
&gt; I do not claim to know the amount of code that would be required to make a<br>
&gt; sync hook to add/remove new/dead exheres. A --regenerate-symtags could be<br>
&gt; difficult as well. A proper client to do realtime browsing would probably be<br>
&gt; better.<br>
&gt;<br>
</div>The symlinks could simply be generated server side and sync&#39;ed by<br>
clients. I think we should distinguish between browsing and searching<br>
however.<br>
<br>
For browsing categories already works fairly well - just like when<br>
browsing through a book you need to know what you&#39;re looking for and<br>
can find it quickly if you do. Searching is where you go for the<br>
index.<br>
<br>
As an example, lets assume that you need to read up on the &#39;+&#39;<br>
operator in your favorite C++ book. Browsing, you would go directly to<br>
the chapter on operators and then skim pages until you get to<br>
operator+. For searching you would look up &#39;+&#39; in the index, then skim<br>
related topics and find operator+ and the page(s) that&#39;s described on.<br>
<br>
As tags can&#39;t be a replacement for categories (as discussed in<br>
previous posts in this thread) </blockquote><div><br>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.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think we should concentrate on<br>
building a better index and possible ideas for using tags beyond<br>
searching or identifying packages.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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=&quot;sdk: java&quot; 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.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt;<br>
&gt; My brain is dying, heres a list of stuff:<br>
&gt; 1) Separate the unique identification of a package from other features (like<br>
&gt; the currently unusable way to browse packages).<br>
</div>Categories are quite usable imo.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt; &nbsp;solution: replace categories with providers<br>
</div>I don&#39;t see how providers actually fix any problems with categories.<br>
<div class="Ih2E3d"></div></blockquote><div><br>It doesn&#39;t - providers fix the uniquely identify packages problems, and the problems with categories is fixed by tags in this proposition.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
&gt; 2) Provide a simple tag based search mechanism.<br>
&gt; &nbsp;solution: add TAGS=&quot;foo bar&quot; to exheres and use inquisitio<br>
&gt; &nbsp;requirement: choose format for TAGS<br>
&gt; &nbsp;todo: implement it<br>
</div>This is easy as long as we decide that&#39;s all we&#39;re going to use tags for.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Agreed.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt;<br>
&gt; 3) Provide a robust browsing mechanism.<br>
&gt; &nbsp; solution a: live search of tags to pare down list in some client (probably<br>
&gt; graphical)<br>
&gt; &nbsp; requirement a: must be fast<br>
&gt; &nbsp; todo a: raise gtkpaludis back from the dead, or use packagekit :-p<br>
</div>I still don&#39;t know why you think the current browsing mechanism sucks<br>
but I suspect you want to use browsing as a search mechanism which is<br>
silly imo. They&#39;re two different methods for locating something and<br>
they&#39;re both very useful imo.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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 &#39;I want an online game&#39;. Unless you enforce an arbitrary rule like &#39;categories must be in alphabetical order drilling down&#39;. It just gets messy at that point and I don&#39;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.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt;<br>
&gt; &nbsp; solution b: export tags as filesystem symlinks<br>
&gt; &nbsp; note b: this pretty much blows<br>
</div>I would block this tbh. The only thing we&#39;d really get from that is a<br>
huge mess of symlinks and complicating the sync process. Tags (without<br>
symlinks) could already give you exactly what you&#39;re after using the<br>
symlinks and an interactive client (like gtkpaludis) could present it<br>
any way you like.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Yeah a good interactive client would be awesome.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
&gt;<br>
&gt; &nbsp; solution c: implement live search with inquisitio - thing tab completion<br>
&gt; that shows a list of more tags that would help pare down the search, plus a<br>
&gt; list of all the packages that match the current command.<br>
&gt;<br>
</div>That would be a feature for an interactive client.<br>
<div class="Ih2E3d"></div></blockquote><div><br>And if an interactive client was made, who would use on disk categories to browse?<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
&gt;<br>
&gt; I think the first two items have good solutions, but the third is a bit<br>
&gt; tougher.<br>
&gt;<br>
</div>I think your solutions are trying to solve the wrong problem &nbsp;:)<br>
<br>
Regards,<br>
<font color="#888888">Bryan Østergaard<br>
</font></blockquote></div><br>I tend to miss the mark a lot, thanks for helping clear things up a bit.<br><br>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&#39;t be repurposed as usable metadata either - all metadata should just be in the exheres. I don&#39;t know how a package manager is coded so if there is huge issues with this, I am sure it will be pointed out.<br>
<br><br>Thanks,<br>Jonathan Dehan<br>