FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-24-2011, 12:31 AM
Zac Medico
 
Default RFC: split up media-sound/ category

On 06/22/2011 11:15 PM, Jes鷖 J. Guerrero Botella wrote:
> Symlinks are clean, and portage has
> always been file-oriented so I see no problem with using them for
> this. All we need is to deference the symlink to find the real name of
> the package and put it in world instead of the symlinked name, so the
> rest of packages won't even need to be retouched to fix the
> dependencies. I don't really know if it's that simple as it sounds,
> but it's an idea.

For some reason, using symlinks to represent tags seems like an odd
approach to me. I think it would be much more sensible to put them in
metadata.xml or an ebuild variable. If for some reason you want symlinks
representing the tags (I don't know why you would), you can always use a
script to generate symlinks from metadata.xml files.
--
Thanks,
Zac
 
Old 06-24-2011, 07:52 AM
Jes鷖 J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/24 Zac Medico <zmedico@gentoo.org>:
> On 06/22/2011 11:15 PM, Jes鷖 J. Guerrero Botella wrote:
>> Symlinks are clean, and portage has
>> always been file-oriented so I see no problem with using them for
>> this. All we need is to deference the symlink to find the real name of
>> the package and put it in world instead of the symlinked name, so the
>> rest of packages won't even need to be retouched to fix the
>> dependencies. I don't really know if it's that simple as it sounds,
>> but it's an idea.
>
> For some reason, using symlinks to represent tags seems like an odd
> approach to me. I think it would be much more sensible to put them in
> metadata.xml or an ebuild variable. If for some reason you want symlinks
> representing the tags (I don't know why you would), you can always use a
> script to generate symlinks from metadata.xml files.

You might not like it, but Gentoo categories have always been
directories, not words into metadata.xml. Most portage tools rely on
that. Not a strong argument, I know that. But someone used this
argument when someone else wanted to put portage into a database
instead of an fs-based tree. That was long ago, admittedly, don't know
if that conversation ever came up again.

I've personally never bothered to learn how to use external tools
anyway, so I just navigate the tree using command line tools when I
need to know something about a given package. I am sure I am not alone
in that regard. I guess I could also "nano metadata.xml", ugh!

Some portage GUIs also use this categorization scheme, like portato or
porthole (not that they are important at all, but they illustrate the
trend).

Maybe it's just my mind model is archaic, but I can't really agree
with tagging for massive trees. I wouldn't drop all my 40 thousand
songs into a single folder and rely on tagging to keep them at hand.
Portage has way more files so I don't see how tagging would be better
for it than it would be for my music collection. I might be too much
influenced by *nix (and DOS) OSes at this stage to be able to see the
advantages of tagging (besides the decorative function), I admit.

--
Jes鷖 Guerrero Botella
 
Old 06-24-2011, 07:55 AM
Ciaran McCreesh
 
Default RFC: split up media-sound/ category

On Fri, 24 Jun 2011 09:52:03 +0200
Jes鷖 J. Guerrero Botella <jesus.guerrero.botella@gmail.com> wrote:
> You might not like it, but Gentoo categories have always been
> directories, not words into metadata.xml.

So tags are in some way related to categories then?

--
Ciaran McCreesh
 
Old 06-24-2011, 08:12 AM
Jes鷖 J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/24 Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> On Fri, 24 Jun 2011 09:52:03 +0200
> Jes鷖 J. Guerrero Botella <jesus.guerrero.botella@gmail.com> wrote:
>> You might not like it, but Gentoo categories have always been
>> directories, not words into metadata.xml.
>
> So tags are in some way related to categories then?

For me, tags would be an abstract concept, related to

A) categories (as in the current dir-based category concept)
B) descriptions
C) maybe, user tastes, so they should be flexible, just like id3

I see them as an instrumental and optional thing, but I don't think
they should be the base of an fs-based system (because then the system
wouldn't be fs-based, that is).

--
Jes鷖 Guerrero Botella
 
Old 06-25-2011, 11:26 AM
Maciej Mrozowski
 
Default RFC: split up media-sound/ category

On Tuesday 21 of June 2011 16:24:07 Micha艂 G贸rny wrote:
> Hello,
>
> As we discussed for a while, the media-sound/ category has grown very
> large and it may be a good idea to split it.
>
> Right now, it contains audio players, editing software, converters,
> sound systems and a lot of other utilities related to sound. Splitting
> that up would make looking up software easier for users (e.g. if I want
> to take a look at what audio players we have, I don't need to see all
> other programs).
>
> What do you think? What new category/-ies do you suggest?

I'd suggest to start thinking about dropping broken categories concept and
introduce (not necessarily replace instantly) flat, but tagged package list
(so that real vector search on tags can be utilized).

--
regards
MM
 
Old 06-25-2011, 11:55 AM
Maciej Mrozowski
 
Default RFC: split up media-sound/ category

On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> On Fri, 24 Jun 2011 09:52:03 +0200
>
> Jes鷖 J. Guerrero Botella <jesus.guerrero.botella@gmail.com> wrote:
> > You might not like it, but Gentoo categories have always been
> > directories, not words into metadata.xml.
>
> So tags are in some way related to categories then?

IMHO the best approach is to forget about categories and:

- make package names unique identifiers (it's not that hard, renaming stuff in
app-xemacs mostly) - categories would serve no purpose as id anymore (though
may need to be provided as backward compatibility - but with symlinks to
ebuilds/${PN} inside)

- move such packages into ${PORTDIR}/ebuilds directory (so that identity is
ensured on filesystem level) - 'ebuilds' name doesn't seem to be reserved
anywhere so good candidate imho.
To those concerned with directory lookup speed (in order to find package by
name) - generated package index file provided in ${PORTDIR}

- extend their metadata.xml (no ebuild variables please) with tags in accepted
format. We should provide dictionary for available tags - necessary in order
to avoid randomly added system tags - tag could be extended when needed -
similar policy to global USE flags for instance

- package manager needs to be make aware of tags of course in order to allow
package list (not tree anymore) searching and filtering
(virtual package tree can be generated from tag - by number of tag occurrences
in packages - for instance all packages with tag "kde" could be "shown"
somewhere within "kde" tag subtree etc)

- no tag related symlinks please

--
regards
MM
 
Old 06-25-2011, 12:22 PM
Kent Fredric
 
Default RFC: split up media-sound/ category

On 25 June 2011 23:55, Maciej Mrozowski <reavertm@gmail.com> wrote:
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (it's not that hard, renaming stuff in
> app-xemacs mostly) - categories would serve no purpose as id anymore (though
> may need to be provided as backward compatibility - but with symlinks to
> ebuilds/${PN} inside)


I think something else that may be important to consider if one is
eliminating category directories is how we'll replace the utility
currently provided by category/metadata.xml

Some things are simply grossly impractical to maintain individual
metadata.xml for reliably due to volume ( ie: dev-perl/* , last I
looked, the metadata.xml in there presently is largely copy-pasted
between dists )

Perhaps we need a new way to apply metadata to a whole host of packages?

Also, categories have extra use for simple convenience of their native
groupings, ie: I've been known to set USE flags/KEYWORDS that apply to
an entire category. Trying to make useflags apply to all packages
with a given tagset would be comparatively messy.

categories also make it easy to do Na飗e iteration of packages
efficiently, ie: for the most part, if you want to iterate all
perl-modules, you just need to iterate dev-perl and perl-core , and
that is all, you're not bogged down by stepping into all the other
categories, loading all their files and working out whether or not
they're perl related. ( Yes, I am aware this has its own caveats, but
if you know of these caveats and they're acceptable to your task, then
its fine )

the 'virtuals' category also is a bundle of fun. I really do not want
to see virtuals identified only by whatever their unique-idenitifier
might be and the tag 'virtual'. Yuck.




--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 06-25-2011, 12:45 PM
Micha艂 G贸rny
 
Default RFC: split up media-sound/ category

On Sat, 25 Jun 2011 13:55:40 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:

> On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> > On Fri, 24 Jun 2011 09:52:03 +0200
> >
> > Jes煤s J. Guerrero Botella <jesus.guerrero.botella@gmail.com> wrote:
> > > You might not like it, but Gentoo categories have always been
> > > directories, not words into metadata.xml.
> >
> > So tags are in some way related to categories then?
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (it's not that hard, renaming
> stuff in app-xemacs mostly) - categories would serve no purpose as id
> anymore (though may need to be provided as backward compatibility -
> but with symlinks to ebuilds/${PN} inside)

And we'll all be doing a lot of ugly ${PN/python-/} and so on. Simplify
things, not make harder just because of some wannabe tag fashion.

--
Best regards,
Micha艂 G贸rny
 
Old 06-25-2011, 12:47 PM
Micha艂 G贸rny
 
Default RFC: split up media-sound/ category

On Sun, 26 Jun 2011 00:22:39 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> Perhaps we need a new way to apply metadata to a whole host of
> packages?
>
> Also, categories have extra use for simple convenience of their native
> groupings, ie: I've been known to set USE flags/KEYWORDS that apply to
> an entire category. Trying to make useflags apply to all packages
> with a given tagset would be comparatively messy.

Yep, we dropped old-style virtuals and now we want a new mess.

--
Best regards,
Micha艂 G贸rny
 
Old 06-25-2011, 02:34 PM
Wyatt Epp
 
Default RFC: split up media-sound/ category

On Sat, Jun 25, 2011 at 08:22, Kent Fredric <kentfredric@gmail.com> wrote:
> I think something else that may be important to consider if one is
> eliminating category directories is how we'll replace the utility
> currently provided by category/metadata.xml
>
> Some things are simply grossly impractical to maintain individual
> metadata.xml for reliably due to volume ( ie: dev-perl/* , last I
> looked, the metadata.xml in there presently is largely copy-pasted
> between dists )
>
Looking at the category/metadata.xml, it's a multilingual dictionary
entry and little else. So make a dictionary of tags (categories).
And what does the latter half have to do with tagging things? Where's
the maintenance? There's the overhead of tagging it once, I'll grant.
And then? Tags are unlikely to change all that frequently once
they've been added (they don't need to).

> Perhaps we need a new way to apply metadata to a whole host of packages?
>
> Trying to make useflags apply to all packages
> with a given tagset would be comparatively messy.
>
Why do you think that? The directory-like notation doesn't even need
to be discarded:
perl_module/* ssl

> categories also make it easy to do Na飗e iteration of packages
> efficiently, ie: for the most part, if you want to iterate all
> perl-modules, you just need to iterate dev-perl and perl-core , and
> that is all, you're not bogged down by stepping into all the other
> categories, loading all their files and working out whether or not
> they're perl related. ( Yes, I am aware this has its own caveats, but
> if you know of these caveats and they're acceptable to your task, then
> its fine )
>
Or just iterate over the perl_module tag.

> the 'virtuals' category also is a bundle of fun. I really do not want
> to see virtuals identified only by whatever their unique-idenitifier
> might be and the tag 'virtual'. Yuck.
>
In the first place, it's still no different: mysql (the virtual) pulls
in db-mysql (or "charles" or whatever name sounds good) whatever else
is available. Or, as I mentioned before, while unique identifiers are
really terribly simple, we are fully capable of working around the
lack of that feature. What prevents virtual/mysql from pulling in
database/mysql?

Regards,
Wyatt
 

Thread Tools




All times are GMT. The time now is 05:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org