<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jonathan Dehan</b> &lt;<a href="mailto:jdehan@gmail.com">jdehan@gmail.com</a>&gt;<br>Date: Thu, Jul 10, 2008 at 1:36 AM<br>
Subject: Re: [Exherbo-dev] Tags vs. categories<br>To: Bernd Steinhauser &lt;<a href="mailto:exherbo@bernd-steinhauser.de">exherbo@bernd-steinhauser.de</a>&gt;<br><br><br>I am going to word the problems a bit differently.<br>
The first is how to uniquely identify a package. This covers on-disk, which should be how the package manager and maintainer sees the package.<br>The second is how to browse or search for a particular package, with or without knowing its name.<br>

<br>I propose having the on-disk format as follows:<br>$packagedir/packages/$repository/$provider/$package-$version-$revision.$format<br>$provider can be {organization,main_developer,homepage}. It does not need to be consistent, for it will only be used to help uniquely identify a package (along with $repository) and all its versions if just the $name is ambiguous.<br>

<br>To help search for a particular package, since replacing categories with providers almost actively discourages browsing, there is a short term workaround and a medium term possible solution.<br><br>For searching, tag support could be artificially added by appending &#39;\n tags: blah blah&#39; to the description field. Thus &#39;inquisitio -s any number of fake tags here&#39; will return good enough results. In addition, using a script to automatically add the current category as a tag name can help. The only thing manually browsing the categories is currently good for is if you forgot a package name, know its in the tree, know what it does/what category it should be in (and that it is in that category), and if you see the name will remember it.  Google is also your friend, in these cases.<br>

<br>For more in depth browsing, and not just tag searching, the tags can be exported as symlinks in <br>$packagedir/tags/{$all-tags}/{$all-tags-plus-the-tag-selected-above}/{etc,etc}/name-provider-repository -&gt;<br>&nbsp;$packagedir/packages/$repository/$provider/$name-$best_available_version_and_revision.$format<br>

<br>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.<br><font color="#888888"><br>- Jonathan Dehan</font><div>
<div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Wed, Jul 9, 2008 at 11:09 PM, Bernd Steinhauser &lt;<a href="mailto:exherbo@bernd-steinhauser.de" target="_blank">exherbo@bernd-steinhauser.de</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;">

Michael Croes schrieb:<div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;So what would a user do to install a package, lets say gcc?<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;First, he would search for the package, which might look<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;like this:<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;inquisitio --search --tags compiler cpp<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;First off, there&#39;s 2 possibilities:<br>
 &nbsp; &nbsp; &nbsp; &nbsp;1. The user knows the package name and types &#39;paludis -i<br>
 &nbsp; &nbsp; &nbsp; &nbsp;package-name&#39;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;2. the user doesn&#39;t know the name and uses something else to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;find the<br>
 &nbsp; &nbsp; &nbsp; &nbsp;name out (presumably inquisitio) and then types &#39;paludis -i<br>
 &nbsp; &nbsp; &nbsp; &nbsp;package-name&#39;<br>
<br>
 &nbsp; &nbsp;Yes, and finding stiff isn&#39;t always that easy, and tags help to find<br>
 &nbsp; &nbsp;things easier, and they help to find alternatives (you can search<br>
 &nbsp; &nbsp;for packages that are similar).<br>
<br>
&nbsp;What I tried to point out is that either way you still tell paludis to install the package using the unique package identifier, not the tags.<br>
</blockquote></div>
Yes, definitely. But it still gives you an advantage, for<br>
non-interactive clients (which atm, we don&#39;t have.<br>
Maybe there could also be a way you can tell paludis to install results<br>
10 of the last search. (Which would imply --pretend.)<br>
But maybe that isn&#39;t a good idea.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Then he would install the package using paludis.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Maybe an installation mode might be possible using tags, if<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the tags are enough to narrow it down, but maybe that might<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;not be a good idea.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The good thing about this is, that 1. and 2. can change, but<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;what the user uses (and he should mainly use the tags) stays<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the same, so a change wouldn&#39;t cause as much confusion as it<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;would if all three change.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;The thing where you go wrong is that you assume that tags are<br>
 &nbsp; &nbsp; &nbsp; &nbsp;part of<br>
 &nbsp; &nbsp; &nbsp; &nbsp;the unique package name. Of course you don&#39;t want tags as part<br>
 &nbsp; &nbsp; &nbsp; &nbsp;of the<br>
 &nbsp; &nbsp; &nbsp; &nbsp;unique package name, you don&#39;t want a category as part of the unique<br>
 &nbsp; &nbsp; &nbsp; &nbsp;package name either. The way this turns out right now in gentoo with<br>
 &nbsp; &nbsp; &nbsp; &nbsp;paludis is that if a package exists in multiple categories you<br>
 &nbsp; &nbsp; &nbsp; &nbsp;need to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;provide paludis with extra information to establish the unique<br>
 &nbsp; &nbsp; &nbsp; &nbsp;identifier for the package.<br>
<br>
 &nbsp; &nbsp;No, not at all. The tags don&#39;t have anything to do with the way the<br>
 &nbsp; &nbsp;packages is identified. They are just additional information that<br>
 &nbsp; &nbsp;the user can access.<br>
<br>
<br>
Do you misunderstood/misread what I wrote? You say tags don&#39;t have anything to do with the way a package is identified, which is exactly what I was saying, would be nice if you could clarify...<br>
</blockquote></div>
Yeah, I guess I misread your mail, sorry.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;If we also (auto-)create some special tags, like system,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;world or installed, it would also be possible to for example<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;search for all installed cpp compilers using --tags<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;installed compilers cpp.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(Currently one would use --kind for that.)<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Let&#39;s do versions with tags too and create the Totally Tagged<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Package<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Manager. All you need to do is figure out tags, you don&#39;t need<br>
 &nbsp; &nbsp; &nbsp; &nbsp;any other<br>
 &nbsp; &nbsp; &nbsp; &nbsp;metadata than tags, that would be useless...<br>
<br>
 &nbsp; &nbsp;Stop the useless nagging, thank you.<br>
<br>
<br>
I hope that my nagging did point out to you that if you&#39;re gonna add tags because a package is installed, you might as well add tags for other stuff that&#39;s not supposed to be in package metadata.<br>
</blockquote></div>
Hm, not sure if I understood you here.<br>
inquisitio would add the tag, if the package is installed, on the fly.<br>
Of course it shouldn&#39;t modify anything on the disk for that.<br>
And of course, we shouldn&#39;t do things without thinking about it, and I<br>
guess that we would realize, when it goes horribly wrong.<br>
(So yes, tags for everything wouldn&#39;t work.)<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&nbsp;<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;But here we see the problem with tags.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Changing tags should not have any affect on 1. or 2., so<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;tags should are not a complete replacement for the<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;categories we currently use.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The should be used for the user interface and only there,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;not for the structure our repos have.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Because tags should not be part of the unique identifier for a<br>
 &nbsp; &nbsp; &nbsp; &nbsp;packge<br>
 &nbsp; &nbsp; &nbsp; &nbsp;this issue doesn&#39;t exist.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;The real issue when dropping categories is how to distinguish<br>
 &nbsp; &nbsp; &nbsp; &nbsp;between<br>
 &nbsp; &nbsp; &nbsp; &nbsp;different packages with the same name, I think it has already been<br>
 &nbsp; &nbsp; &nbsp; &nbsp;mentioned on the mailing list before. Your email shows that<br>
 &nbsp; &nbsp; &nbsp; &nbsp;having tags<br>
 &nbsp; &nbsp; &nbsp; &nbsp;fixes the issues you see with categories and shows that if you<br>
 &nbsp; &nbsp; &nbsp; &nbsp;use tags<br>
 &nbsp; &nbsp; &nbsp; &nbsp;as if they were categories, stuff would go wrong. That&#39;s why<br>
 &nbsp; &nbsp; &nbsp; &nbsp;they&#39;re not<br>
 &nbsp; &nbsp; &nbsp; &nbsp;called categories, they&#39;re different.<br>
<br>
 &nbsp; &nbsp;See, you didn&#39;t really read what I wrote.<br>
 &nbsp; &nbsp;What you are trying to solve belongs to point 1. in my list.<br>
 &nbsp; &nbsp;I was *only* talking about what the user uses.<br>
<br>
<br>
Actually the notion of tags solves point 3. Tags and categories are somewhat similar, but with categories as implemented in gentoo you limit packages to one category. If you extend this so packages can be in more than one category then you might as well call it tags so you can mix more metadata in. In the end you can still have a multi-level structure where you can find your packages, so that should not be an issue for the end user.<br>


</blockquote></div>
Well, in the end, it is more what you are calling it, isn&#39;t it? ;)<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
&nbsp;<br>
<br>
 &nbsp; &nbsp;You could even use a system for the actual storage, inspired by tags<br>
 &nbsp; &nbsp;or similar. What I supposed gives you the ability to basically<br>
 &nbsp; &nbsp;select just about any solution, because you don&#39;t have to worry<br>
 &nbsp; &nbsp;about the user interface as much as you had to before.<br>
<br>
<br>
Which you pointed out in your previous mail to suck because if the tags change packages would have to be moved around on the &#39;system for actual storage&#39;.<br>
</blockquote></div>
Well, I was referring to something &quot;tag-like&quot; whatever that might be.<br>
I&#39;m not really in favor of such a solution, I just wanted to say, that<br>
what I proposed allows you to freely choose the solution for 1. and 2.<br>
There might be other solutions for 3. that achieve that, too, of course. :)<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t think point 2 is a real issue. It&#39;s more a personal preference how you should lay out packages.<br>
<br>
So to answer your three points of concern:<br>
1. Not changed by using tags, only changed by removing categories. Not solved by categories either because 2 packages can have the same name and be in the same category. Solved by having a unique identifier for a package (which you need anyway), then the structure on disk could perhaps be /path/to/repository/[unique-identifier]. There&#39;s other ways too, but they probably all end up using the unique identifier as part of the path.<br>


</blockquote></div>
It&#39;s not that easy, because you have to think about performance, too.<br>
But basically yes, that&#39;s the main problem.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. Let&#39;s say I work on package foo. I don&#39;t really care if the dir with files is /path/to/repository/app-useless/foo or if the dir with is /path/to/repository/foo, I still end up with the same dir with files. I think this has nothing to do with tags again, only with removing categories. Then again, even removing categories doesn&#39;t really change anything, because in gentoo the category is just part of the unique identifier for a package. The only real difference is that if I work on half the packages in app-useless, they now might be all over the place, because I also work on (app-useless/)zoo and (app-useless/)aoo. So the list which also includes the packages I work on has now grown from just the 50% of app-useless to all availible packages in a repository... BUT: if you&#39;re sane you&#39;re probably not modifying stuff inside the repository, but rather somewhere outside of the repository where there&#39;s still only those packages I work on, and nothing else...<br>


</blockquote></div>
Working on stuff outside of the repository isn&#39;t really a nice thing,<br>
because you lose the functionality that git provides.<br>
What I mainly wanted to say with bringing up a difference between 1. and<br>
2. is, that basically the layout of 1. could be very very ugly (looking<br>
at it as a human being). (But maybe doesn&#39;t have to be ugly.)<br>
But only, if you, at the same time, provide something nice in the repo,<br>
that the devs can work on.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. If we start by using the category as a tag for every package, then by searching for the tag www-client I would get exactly the same as there&#39;s in the category www-client. Now I think that with tags you can certainly improve a lot from here, but in worst case it&#39;s just as bad or good as categories, so this seems like an absolute non-issue to me...<br>


</blockquote></div>
Absolutely.<div><div></div><div><br>
<br>
Regards,<br>
Bernd<br>
<br>
<br>
_______________________________________________<br>
Exherbo-dev mailing list<br>
<a href="mailto:Exherbo-dev@lists.exherbo.org" target="_blank">Exherbo-dev@lists.exherbo.org</a><br>
<a href="http://lists.exherbo.org/mailman/listinfo/exherbo-dev" target="_blank">http://lists.exherbo.org/mailman/listinfo/exherbo-dev</a><br>
</div></div></blockquote></div><br>
</div></div></div><br>