Michael Croes schrieb:
So what would a user do to install a package, lets say gcc?
First, he would search for the package, which might look like this:
inquisitio --search --tags compiler cpp
First off, there's 2 possibilities:
1. The user knows the package name and types 'paludis -i package-name'
2. the user doesn't know the name and uses something else to find the
name out (presumably inquisitio) and then types 'paludis -i
package-name'
Yes, and finding stiff isn't always that easy, and tags help to find
things easier, and they help to find alternatives (you can search for
packages that are similar).
Then he would install the package using paludis.
Maybe an installation mode might be possible using tags, if the tags are
enough to narrow it down, but maybe that might not be a good idea.
The good thing about this is, that 1. and 2. can change, but what the
user uses (and he should mainly use the tags) stays the same, so a
change wouldn't cause as much confusion as it would if all three change.
The thing where you go wrong is that you assume that tags are part of
the unique package name. Of course you don't want tags as part of the
unique package name, you don't want a category as part of the unique
package name either. The way this turns out right now in gentoo with
paludis is that if a package exists in multiple categories you need to
provide paludis with extra information to establish the unique
identifier for the package.
No, not at all. The tags don't have anything to do with the way the
packages is identified. They are just additional information that the
user can access.
If we also (auto-)create some special tags, like system, world or
installed, it would also be possible to for example search for all
installed cpp compilers using --tags installed compilers cpp.
(Currently one would use --kind for that.)
Let's do versions with tags too and create the Totally Tagged Package
Manager. All you need to do is figure out tags, you don't need any other
metadata than tags, that would be useless...
Stop the useless nagging, thank you.
But here we see the problem with tags.
Changing tags should not have any affect on 1. or 2., so tags should are
not a complete replacement for the categories we currently use.
The should be used for the user interface and only there, not for the
structure our repos have.
Because tags should not be part of the unique identifier for a packge
this issue doesn't exist.
The real issue when dropping categories is how to distinguish between
different packages with the same name, I think it has already been
mentioned on the mailing list before. Your email shows that having tags
fixes the issues you see with categories and shows that if you use tags
as if they were categories, stuff would go wrong. That's why they're not
called categories, they're different.
See, you didn't really read what I wrote.
What you are trying to solve belongs to point 1. in my list.
I was *only* talking about what the user uses.
You could even use a system for the actual storage, inspired by tags or
similar. What I supposed gives you the ability to basically select just
about any solution, because you don't have to worry about the user
interface as much as you had to before.
Regards,
Bernd
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
