[gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Norberto Bensa]

Excuse me for thread hijack.

Would it make sense to add (for example):

  kde-games
  gnome-games

?

Or the other way around. Move kde-base/kmail to mail-client/kmail ?

What about both ways using symlinks: kde-games/ksudoku -> games-puzzle/ksudoku ?


Thanks,
Norberto

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[AllenJB]

Norberto Bensa wrote:
> Excuse me for thread hijack.
> 
> Would it make sense to add (for example):
> 
>   kde-games
>   gnome-games
> 
> ?
> 
> Or the other way around. Move kde-base/kmail to mail-client/kmail ?
> 
> What about both ways using symlinks: kde-games/ksudoku -> games-puzzle/ksudoku ?
> 
> 
> Thanks,
> Norberto
> 
Personally I prefer all the "official" kde package in kde-base - it 
allows me to quickly know that this given package is part of the 
official KDE package set.

I don't see a need for kde-games - it's pretty clear from the 
descriptions which of the kde-base packages are games, and for the 
reason stated above I don't like the idea of mixing "official" and 
"unofficial" packages.

I suspect symlinks are likely to cause issues (what happens if you try 
to install both kde-games/ksudoku and games-puzzle/ksudoku?) and as far 
as I know are never used in the package tree.

Package moves like this are occasionally going to happen, no matter how 
you structure the repository. The only real question here is whether 
this is a package move (in which case, I believe, portage goes through 
and updates /etc/portage/package.*, world and possibly custom sets 
contents automatically) or just a package mask (in which case it's up to 
the user to do all those updates)

AllenJB

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Rémi Cardona]

Le 01/02/2009 18:32, Norberto Bensa a écrit :
> Excuse me for thread hijack.
>
> Would it make sense to add (for example):
>
>    gnome-games

gnome-games is already the name of a package that contains all official 
GNOME games. Only a handful are also released and packaged separately.

Useless for us IMHO.

Cheers,

Rémi

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Luca Barbato]

Norberto Bensa wrote:
> Excuse me for thread hijack.
> 
> Would it make sense to add (for example):
> 
>   kde-games
>   gnome-games

I'm afraid not.
> 
> ?
> 
> Or the other way around. Move kde-base/kmail to mail-client/kmail ?

not sure how useful could be but could make more sense even if right now 
kde-base contains everything comes from the main kde distribution.

> What about both ways using symlinks: kde-games/ksudoku -> games-puzzle/ksudoku ?

No symlinks and no aliases please.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Norberto Bensa]

On Mon, Feb 2, 2009 at 7:15 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> Norberto Bensa wrote:

>> What about both ways using symlinks: kde-games/ksudoku ->
>> games-puzzle/ksudoku ?
>
> No symlinks and no aliases please.

Ok.

My idea, if someone is wondering, was asnwer the questions: "what
email clients are available?" and "which one is for kde?" A simple "ls
-l /usr/portage/mail-client/" would show which ones. I thought it
could be useful.

Regards,
Norberto

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Maciej Mrozowski]

On Monday 02 of February 2009 22:15:53 Luca Barbato wrote:

> not sure how useful could be but could make more sense even if right now
> kde-base contains everything comes from the main kde distribution.

To be more specific, kde-base contains everything (and only) that is 
distributed as KDE stable release (no extragear included). And it causes 
confusion as when packages are dropped from KDE release schedule (so they 
usually go back to extragear to release when they want), one needs to look to 
new place for them (in kde-misc or somewhere else).
Actually categories are bad idea imho.
I was thinking, maybe it would be possible to drop categories completely in 
the future (maybe keeping symlinks for compatibility and to ease migration) 
and to put *all* packages in one directory - that would require making all 
names unique of course.
"Categorization" could be provided for user/search tools as tag clouds being 
defined in metadata.xml as vector of tag:weight values where tag would be some 
word from defined dictionary (word like "mail" "client" "kde" "dns" or sth) 
and weight - real value [0,1] defining how relevant is that tag.
For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc -> 
all/gcc.
But that's just an off-topic.

-- 
regards
MM

----------------------------------------------------------------------
Nie boj sie przyszlosci!
Zapytaj wrozke >>  http://link.interia.pl/f2049 

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Sun, 2009-02-01 at 19:58 +0100, Rémi Cardona wrote:
> Le 01/02/2009 18:32, Norberto Bensa a écrit :
> > Excuse me for thread hijack.
> >
> > Would it make sense to add (for example):
> >
> >    gnome-games
> 
> gnome-games is already the name of a package that contains all official 
> GNOME games. Only a handful are also released and packaged separately.
> 
> Useless for us IMHO.

That said, I'm still threatening to split gnome-games up to individual
packages one rainy day. But if that goes through (time-wise and has team
agreement), the individual games would be in the suitable games-*
category (games-arcade, games-board, etc) with a gnome-extra/gnome-games
still in place (one day gnome-base/) - newer versions being meta
packages pulling in the individual official games.
And not in a gnome-games/ category. Then you can find gnome-games meta
package from gnome-*/ category and individual games in their suitable
category (glchess is a cool board game, etc)..


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Category tags on packages (was: new categories:)

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote:
> On Monday 02 of February 2009 22:15:53 Luca Barbato wrote:
> 
> > not sure how useful could be but could make more sense even if right now
> > kde-base contains everything comes from the main kde distribution.
> 
> To be more specific, kde-base contains everything (and only) that is 
> distributed as KDE stable release (no extragear included). And it causes 
> confusion as when packages are dropped from KDE release schedule (so they 
> usually go back to extragear to release when they want), one needs to look to 
> new place for them (in kde-misc or somewhere else).
> Actually categories are bad idea imho.
> I was thinking, maybe it would be possible to drop categories completely in 
> the future (maybe keeping symlinks for compatibility and to ease migration) 
> and to put *all* packages in one directory - that would require making all 
> names unique of course.
> "Categorization" could be provided for user/search tools as tag clouds being 
> defined in metadata.xml as vector of tag:weight values where tag would be some 
> word from defined dictionary (word like "mail" "client" "kde" "dns" or sth) 
> and weight - real value [0,1] defining how relevant is that tag.
> For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc -> 
> all/gcc.
> But that's just an off-topic.


I agree that a tag kind of approach would be nice. Someone should
actually do work on it.
Here's a random similar idea that I think might work well as a GLEP
proposition, that I was about to reply to a different subthread before
noticing this post:

Packages metadata.xml can be extended with an unlimited amount of <tag>
elements, whose #text can be a tag string, but one that is limited to a
given list in some other place - to have a list of existing tags and not
just randomly have tags for everything. Make an effort to populate all
packages with sensible tags. Then write tools around it that can show
you all packages with a given tag or tags, what tags exist, etc. Those
will be your new categories that answer the question of "what mail
clients are there" (mail-client tag) or "what mail clients are there
using GTK+, well suited for a GNOME environment" (mail-client and gnome
tags).
Keep categories in place for repository tree sanity (not a huge amount
of directories with all packages being sibling dirs) and easier
implementation of it all. No-one really types in the categories anyway,
and with a tool that deals with the tags, you don't look at the subdirs
either - so categories for the user just become a way to differentiate
packages with the same name for the few cases there are equal names.
However those that prefer the categories approach, can keep using it.
Developers also deal with categories, but that's easy enough to keep
going as is.
Less radical, less controversial, better viability to actually get done.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Nirbheek Chauhan]

On Tue, Feb 3, 2009 at 6:47 AM, Mart Raudsepp <leio@gentoo.org> wrote:
> I agree that a tag kind of approach would be nice. Someone should
> actually do work on it.
> Here's a random similar idea that I think might work well as a GLEP
> proposition, that I was about to reply to a different subthread before
> noticing this post:
<snip random idea :p>

The simplest method I can think of is:

${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku

Yes, that's a symlink inside a new root-directory "tags" where "games"
is a tag and "puzzles" is a sub-tag. If for some reason we get an
explosion in sudoku games in portage (with weird names), we can make a
new sub-tag "games/puzzles/sudoku/"

${PORTDIR}/tags/games/puzzles/sudoku/ksudoku -> ../../../../kde-base/ksudoku

And this won't cause any problems since "higher" tags are inherited.
Another usage of tagging could be marking packages as "deprecated" to
ease out removal of old packages.

${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok

/me hides from the amarok lovers.

Symlinking has the advantage of being a natural extension of our
favourite flat-file db[1] to tagging. Having a new folder instead of
symlinking inside other categories has the advantage of being
backwards-compatible, and will also prevent an explosion in the number
of categories in the root dir.

FWIW, git (atleast) preserves symlinks in source trees, so once the
move to git is complete, there will be no obstacles left in this
thing's implementation ;)


1. That's the portage tree, btw :p

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] new categories:

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Maciej Mrozowski wrote:
> I was thinking, maybe it would be possible to drop categories completely in 
> the future (maybe keeping symlinks for compatibility and to ease migration) 
> and to put *all* packages in one directory - that would require making all 
> names unique of course.

Tags for packages are not a new idea; it's been brought up on this list
before. But I really, really, don't like the idea of renaming packages.

So, what, we're turning into Debian? Arbitrary package (re)naming? Yuck!
Our current policy is to call the package what upstream calls it. We can
do this largely *because* of categories. There are a few noncompliant
packages, but the system generally works pretty well.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] new categories:

[George Shapovalov]

Tuesday, 3. February 2009, Josh Saddler Ви написали:
> Maciej Mrozowski wrote:
> > I was thinking, maybe it would be possible to drop categories completely
> > in the future (maybe keeping symlinks for compatibility and to ease
> > migration) and to put *all* packages in one directory - that would
> > require making all names unique of course.
> So, what, we're turning into Debian? Arbitrary package (re)naming? Yuck!
> Our current policy is to call the package what upstream calls it. We can
> do this largely *because* of categories. There are a few noncompliant
> packages, but the system generally works pretty well.

Besides, in my opinion, the ability to see "what's there" in at least 
minimally categorized way without having to resort to using some special 
tools or going to some website is worht something. In this vain I was 
proposing going the opposite direction - to allow arbitrary nesting of 
categories, like going sci-math -> sci/math and deeper (then packages would 
naturally be specified by "FQEN" - fully qualified ebuild names). Its not 
like tree walker would be the most complex part of code in portage..

George

Re: [gentoo-dev] new categories:

[Denis Dupeyron]

On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov <george@gentoo.org> wrote:
> Besides, in my opinion, the ability to see "what's there" in at least
> minimally categorized way without having to resort to using some special
> tools or going to some website is worht something. In this vain I was
> proposing going the opposite direction - to allow arbitrary nesting of
> categories, like going sci-math -> sci/math and deeper (then packages would
> naturally be specified by "FQEN" - fully qualified ebuild names). Its not
> like tree walker would be the most complex part of code in portage..

Actually we'd want both tags and nesting. They don't address the same issue.

Arbitrary nesting of categories allows better management and storing
of ebuilds. It could also allow a meta-ebuild to depend on a whole
subcategory to ease maintenance of said meta-ebuild. It's more a
developer's feature.

Tags allow ebuilds to appear as being pertinent to more
(sub-)categories than just the one they're stored into. It may help
some of us locate packages they need in a better and/or faster way.
It's more of a user's feature.

Denis.

[gentoo-dev] Re: new categories:

[Steve Long]

Denis Dupeyron wrote:

> On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov <george@gentoo.org>
> wrote:
>> Besides, in my opinion, the ability to see "what's there" in at least
>> minimally categorized way without having to resort to using some special
>> tools or going to some website is worht something. In this vain I was
>> proposing going the opposite direction - to allow arbitrary nesting of
>> categories, like going sci-math -> sci/math and deeper (then packages
>> would naturally be specified by "FQEN" - fully qualified ebuild names).
>> Its not like tree walker would be the most complex part of code in
>> portage..
> 
> Actually we'd want both tags and nesting. They don't address the same
> issue.
> 
> Arbitrary nesting of categories allows better management and storing
> of ebuilds. It could also allow a meta-ebuild to depend on a whole
> subcategory to ease maintenance of said meta-ebuild. It's more a
> developer's feature.
>
That sounds very similar to sets? Sorry if I'm missing something obvious,
but I thought sets were used with kde4; if they are unavailable to the
ebuild author, perhaps a suitably-defined extension (for in-tree sets)
might be useful?
The obvious advantage being that they are not tied to a specific category,
ofc; could you expand a bit on 'better management and storing'?

> Tags allow ebuilds to appear as being pertinent to more
> (sub-)categories than just the one they're stored into. It may help
> some of us locate packages they need in a better and/or faster way.
> It's more of a user's feature.
> 
Tags sound cool. I'm opposed to losing the current single flat category
schema, fwtw, unless it enables something majorly-useful. It's *way* better
than other distros (I am deadset against losing all categorisation) and
still nice and immediate.

[gentoo-dev] Re: new categories:

[Steve Long]

Denis Dupeyron wrote:

> On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov <george@gentoo.org>
> wrote:
>> Besides, in my opinion, the ability to see "what's there" in at least
>> minimally categorized way without having to resort to using some special
>> tools or going to some website is worht something. In this vain I was
>> proposing going the opposite direction - to allow arbitrary nesting of
>> categories, like going sci-math -> sci/math and deeper (then packages
>> would naturally be specified by "FQEN" - fully qualified ebuild names).
>> Its not like tree walker would be the most complex part of code in
>> portage..
> 
> Actually we'd want both tags and nesting. They don't address the same
> issue.
> 
> Arbitrary nesting of categories allows better management and storing
> of ebuilds. It could also allow a meta-ebuild to depend on a whole
> subcategory to ease maintenance of said meta-ebuild. It's more a
> developer's feature.
>
That sounds very similar to sets? Sorry if I'm missing something obvious,
but I thought sets were used with kde4; if they are unavailable to the
ebuild author, perhaps a suitably-defined extension (for in-tree sets)
might be useful?
The obvious advantage being that they are not tied to a specific category,
ofc; could you expand a bit on 'better management and storing'?

> Tags allow ebuilds to appear as being pertinent to more
> (sub-)categories than just the one they're stored into. It may help
> some of us locate packages they need in a better and/or faster way.
> It's more of a user's feature.
> 
Tags sound cool. I'm opposed to losing the current single flat category
schema, fwtw, unless it enables something majorly-useful. It's *way* better
than other distros (I am deadset against losing all categorisation) and
still nice and immediate.

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Luca Barbato]

Nirbheek Chauhan wrote:
> On Tue, Feb 3, 2009 at 6:47 AM, Mart Raudsepp <leio@gentoo.org> wrote:
>> I agree that a tag kind of approach would be nice. Someone should
>> actually do work on it.
>> Here's a random similar idea that I think might work well as a GLEP
>> proposition, that I was about to reply to a different subthread before
>> noticing this post:
> <snip random idea :p>
> 
> The simplest method I can think of is:
> 
> ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
> 

Sounds nice and has the added value to be possible to opt out and to
not hinder who do not care about it.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Federico Ferri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nirbheek Chauhan wrote:
> ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
> ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
../../../../kde-base/ksudoku
> ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok

- --

I like the tag idea.
I don't like tag as described above.
I feel having tags organized in hierarchical way is inappropriate.
that just makes another organization of packages in categories.

tags <-> packages is a many-to-many relation.



btw, if the DESCRIPTION field is well written, it functions as a tag.
e.g.:

$ eix -c -S dockapp -S net
[N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU,
Net, Power, df, seti
[N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network
interfaces.
[N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet
connections to and from your computer.
[N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time,
date, and internet time
[N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp)
[N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp
[N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp
Found 7 matches.

although DESCRIPTION doesn't contain "obvious" tags.
perhaps it's worth the addition of a TAGS field (?) that has to be
searched just like DESCRIPTION


just my 2E-2
Federico Ferri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmPHZIACgkQV/B5axfzrPu9ewCgr2XRqbTy9XycR5g0KeFWtOnV
ou8An2WKDEeIsPioWHn/lVEtPrHF4QNg
=GvLh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Nirbheek Chauhan]

On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri <mescalinum@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nirbheek Chauhan wrote:
>> ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
>> ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
> ../../../../kde-base/ksudoku
>> ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok
>
> - --
>
> I like the tag idea.
> I don't like tag as described above.
> I feel having tags organized in hierarchical way is inappropriate.
> that just makes another organization of packages in categories.

KDE and OLPC are looking towards hierarchical tags as the future of
content management. People don't really use folders, they use tags:

"Holidays" > "2008" > "Switzerland"
"Open Source" > "Gentoo" > "portage"

>
> tags <-> packages is a many-to-many relation.

Aren't tags _made_ to be many-to-many?


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Nirbheek Chauhan]

On Sun, Feb 8, 2009 at 11:40 PM, Nirbheek Chauhan
<nirbheek.chauhan@gmail.com> wrote:
> On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri <mescalinum@gentoo.org> wrote:
>> tags <-> packages is a many-to-many relation.
>
> Aren't tags _made_ to be many-to-many?

ie, symlinking can allow that kind of relationship


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Federico Ferri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nirbheek Chauhan wrote:
>> I like the tag idea. I don't like tag as described above. I feel
>> having tags organized in hierarchical way is inappropriate. that
>> just makes another organization of packages in categories.
>
> KDE and OLPC are looking towards hierarchical tags as the future of
>  content management. People don't really use folders, they use
> tags:
>
> "Holidays" > "2008" > "Switzerland" "Open Source" > "Gentoo" >
> "portage"
>

the above looks exactly like folders (unless you elaborate on that)

I don't know what KDE or OLPC are thinking. when I tag my stuff I'd
probably have:
photo001.jpg {2008,holidays,nature,switzerland}
photo002.jpg {2008,holidays,fun,switzerland,zurich}
photo158.jpg {2009,computer,me,misc}
(the order of tags here is alphabetical)

> tags <-> packages is a many-to-many relation.
>>
>> Aren't tags _made_ to be many-to-many?
>
> ie, symlinking can allow that kind of relationship

can you show an example (of many-2-many relation, with symlinks)?


Federico Ferri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmPJHsACgkQV/B5axfzrPtbpACfcq8qpQdkneWplS8H3XgEiry1
1qUAoKZcMUGDyro8nHwrSvNwflm0nyGn
=PV0+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Am Sonntag, den 08.02.2009, 23:41 +0530 schrieb Nirbheek Chauhan:
> On Sun, Feb 8, 2009 at 11:40 PM, Nirbheek Chauhan
> <nirbheek.chauhan@gmail.com> wrote:
> > On Sun, Feb 8, 2009 at 11:29 PM, Federico Ferri <mescalinum@gentoo.org> wrote:
> >> tags <-> packages is a many-to-many relation.
> >
> > Aren't tags _made_ to be many-to-many?
> 
> ie, symlinking can allow that kind of relationship
> 

No, symlinking sucks for various reasons. Here are some:
- filesystem access is slow
- moving packages from one category to another gets even worse because
you have to check for deadlinks
- you have to check for deadlinks anyway because people forget to remove
them when removing packages
- good luck with that on Gentoo/Prefix-Interix


-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail     : dev-zero@gentoo.org
GnuPG FP   : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]

Am Sonntag, den 08.02.2009, 18:59 +0100 schrieb Federico Ferri:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Nirbheek Chauhan wrote:
> > ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
> > ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku ->
> ../../../../kde-base/ksudoku
> > ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok
> 
> - --
> 
> I like the tag idea.
> I don't like tag as described above.
> I feel having tags organized in hierarchical way is inappropriate.
> that just makes another organization of packages in categories.
> 
> tags <-> packages is a many-to-many relation.
> 
> 
> 
> btw, if the DESCRIPTION field is well written, it functions as a tag.

Please, don't.

> e.g.:
> 
> $ eix -c -S dockapp -S net
> [N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU,
> Net, Power, df, seti
> [N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network
> interfaces.
> [N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet
> connections to and from your computer.
> [N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time,
> date, and internet time
> [N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp)
> [N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp
> [N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp
> Found 7 matches.
> 
> although DESCRIPTION doesn't contain "obvious" tags.
> perhaps it's worth the addition of a TAGS field (?) that has to be
> searched just like DESCRIPTION

It's metadata-stuff, why not put it there?

You have two possibilities:

a) Introduce new elements:
<tags>
  <tag>foo</tag>
  <tag>bar</tag>
</tags>

b) Think of herds as tags, then you have many packages already tagged.
To be able to add new herds/tags without messing up with the
maintainer-info, I'd then introduce new attributes for <maintainer> and
instead of writing <herd>foo</herd> meaning that a package is maintainer
by team "foo" just write <maintainer type="team">foo</maintainer>
instead.
Then you can use the "herd" element in metadata.xml freely as a tag.

Cheers,
Tiziano


-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail     : dev-zero@gentoo.org
GnuPG FP   : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Angelo Arrifano]

I would keep existing categories and add a new TAG metadata to existing
ebuilds. Something like TAG="kde music player lyrics lastfm
visualization" for amarok, as example.

A public list of *ALLOWED* tags would be published on our www
infrastructures.

Then during the portage metadata regeneration process, a new tags dir
(under portage metadata dir) would be created with files for EACH tag.
Each tag file would include the fully qualified name for the ebuilds in
which the tag is present.

This way, given a set of tags, it is easy and fast too lookup which
ebuilds match the given tags and how much (percentage) they match them.

For example:
The user searches for "music gnome lyrics"

exaile is tagged as "(...) music gnome lyrics"
gnome-mplayer is tagged as "(...) music gnome"
amarok is tagged as "(...) music lyrics"
(...)

So we can give an interest-ordered list to the user.

Just my two cents,
Thanks all
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Rémi Cardona]

Le 08/02/2009 20:07, Angelo Arrifano a écrit :
> I would keep existing categories and add a new TAG metadata to existing
> ebuilds. Something like TAG="kde music player lyrics lastfm
> visualization" for amarok, as example.

If anything, this sort of extra information should go to metadata.xml.

Cheers,

Rémi

[gentoo-dev] Re: Category tags on packages (was: new categories:)

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Sun, 08 Feb 2009 19:07:58 +0000
Angelo Arrifano <miknix@gentoo.org> wrote:

> I would keep existing categories and add a new TAG metadata to
> existing ebuilds. Something like TAG="kde music player lyrics lastfm
> visualization" for amarok, as example.
> 
> A public list of *ALLOWED* tags would be published on our www
> infrastructures.
> 
> Then during the portage metadata regeneration process, a new tags dir
> (under portage metadata dir) would be created with files for EACH tag.
> Each tag file would include the fully qualified name for the ebuilds
> in which the tag is present.
> 
> This way, given a set of tags, it is easy and fast too lookup which
> ebuilds match the given tags and how much (percentage) they match
> them.
> 
> For example:
> The user searches for "music gnome lyrics"
> 
> exaile is tagged as "(...) music gnome lyrics"
> gnome-mplayer is tagged as "(...) music gnome"
> amarok is tagged as "(...) music lyrics"
> (...)
> 
> So we can give an interest-ordered list to the user.
> 
> Just my two cents,
> Thanks all

I've always thought it would be cool to have user-created tag clouds,
del.icio.us-style, on packages.g.o.  I expect this would be a hell of a
lot of work to set up however.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Category tags on packages (was: new categories:)

[Federico Ferri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Hill wrote:
>
> I've always thought it would be cool to have user-created tag
> clouds, del.icio.us-style, on packages.g.o.  I expect this would be
> a hell of a lot of work to set up however.

initially, packages could be automatically tagges, based on the
following criteria:
- - category
- - common* words found in $DESCRIPTION
- - common* words found in metadata.xml:<longdescription> if any
- - extend the above with description found on the net

plus:
- - a hidden tag to indicate that tags were assigned automatically, to
be removed whenever the pkg tags are "reviewed" by a human


+= 2E-2

Federico Ferri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmPXfEACgkQV/B5axfzrPu46wCdFaTMWf4LSGCRHJJFB0xh0Vio
yYwAn0siZ5oIaec3H2PfDEc6q/t02b6D
=1Pjf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Maciej Mrozowski]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Sunday 08 of February 2009 19:51:29 Tiziano Müller wrote:

> It's metadata-stuff, why not put it there?
>
> You have two possibilities:
>
> a) Introduce new elements:
> <tags>
>   <tag>foo</tag>
>   <tag>bar</tag>
> </tags>
>
> b) Think of herds as tags, then you have many packages already tagged.
> To be able to add new herds/tags without messing up with the
> maintainer-info, I'd then introduce new attributes for <maintainer> and
> instead of writing <herd>foo</herd> meaning that a package is maintainer
> by team "foo" just write <maintainer type="team">foo</maintainer>
> instead.
> Then you can use the "herd" element in metadata.xml freely as a tag.

That's basically exactly what I've proposed, I'd just add (possibly optional) 
weight or relevance of tag as well, for example:

<tags>
  <tag>foo</tag>
  <!-- some less relevant tag -->
  <tag weight="0.5">bar</tag>
</tags>

as one cannot forget that tag search is *vector*, not binary search - so there 
are more possibilities to explore.

Btw, too bad, metadat XML schema is written in DTD and not in some easier to 
read more expressive way - like RelaxNG.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]