<br><br><div class="gmail_quote">On Thu, Jul 10, 2008 at 6:49 PM, Ciaran McCreesh &lt;<a href="mailto:ciaran.mccreesh@googlemail.com">ciaran.mccreesh@googlemail.com</a>&gt; wrote:<br><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 Thu, 10 Jul 2008 01:37:19 -0400<br>
&quot;Jonathan Dehan&quot; &lt;<a href="mailto:jdehan@gmail.com">jdehan@gmail.com</a>&gt; wrote:<br>
&gt; I propose having the on-disk format as follows:<br>
&gt; $packagedir/packages/$repository/$provider/$package-$version-$revision.$format<br>
&gt; $provider can be {organization,main_developer,homepage}. It does not<br>
&gt; need to be consistent, for it will only be used to help uniquely<br>
&gt; identify a package (along with $repository) and all its versions if<br>
&gt; just the $name is ambiguous.<br>
<br>
</div>There&#39;s a non-obvious downside to doing this: for sane performance, we<br>
want directories with typically between ten and a hundred items in<br>
them. As it happens, categories the way they are currently fit into<br>
this.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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 - <a href="http://pim.kde.org">http://pim.kde.org</a> instead of <a href="http://kde.org">http://kde.org</a> 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.<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; For more in depth browsing, and not just tag searching, the tags can<br>
&gt; be exported as symlinks in<br>
&gt; $packagedir/tags/{$all-tags}/{$all-tags-plus-the-tag-selected-above}/{etc,etc}/name-provider-repository<br>
&gt; -&gt;<br>
&gt; &nbsp;$packagedir/packages/$repository/$provider/$name-$best_available_version_and_revision.$format<br>
&gt;<br>
&gt; Exporting all permutations of tags as symlinks on the filesystem<br>
&gt; makes it very flexible to browse for packages, at least until a<br>
&gt; proper interactive client comes around.<br>
<br>
</div>That strikes me as a maintenance pain in the ass.<br>
<br>
--<br>
<font color="#888888">Ciaran McCreesh<br>
</font></blockquote><div><br>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.<br>
<br><br>My brain is dying, heres a list of stuff:<br>1) Separate the unique identification of a package from other features (like the currently unusable way to browse packages).<br>&nbsp;solution: replace categories with providers<br>
&nbsp;requirement: keep item count of any given directory under 100<br>&nbsp;todo: make a fake tree from existing data to support a particular scheme<br><br>2) Provide a simple tag based search mechanism.<br>&nbsp;solution: add TAGS=&quot;foo bar&quot; to exheres and use inquisitio<br>
&nbsp;requirement: choose format for TAGS<br>&nbsp;todo: implement it<br><br>3) Provide a robust browsing mechanism.<br>&nbsp; solution a: live search of tags to pare down list in some client (probably graphical)<br>&nbsp; requirement a: must be fast<br>
&nbsp; todo a: raise gtkpaludis back from the dead, or use packagekit :-p<br><br>&nbsp; solution b: export tags as filesystem symlinks<br>&nbsp; note b: this pretty much blows<br><br>&nbsp; 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.<br>
<br><br>I think the first two items have good solutions, but the third is a bit tougher.<br></div></div>