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-22-2011, 09:38 AM
Joshua Saddler
 
Default RFC: split up media-sound/ category

On Tue, 21 Jun 2011 16:24:07 +0200
Michał Górny <mgorny@gentoo.org> 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?
>

Whatever happened to implementing tags for the Portage tree? The idea
behind tags was to avoid spamming users with more and more
directories, especially for apps that are hard to categorize. Which,
arguably, is most of them. We have tags for weblog content/topics;
tags for ebuilds are also a good idea.

Splitting up the media-* categories doesn't solve any problems for
the packages that do many different things, whether encoding,
playing, editing, wrapping, connecting, etc. Many media apps belong
in 3 or 4 or more categories. Tags are the right solution for these,
rather than being pigeonholed into just one category, which only
reflects one use.
 
Old 06-22-2011, 09:55 AM
Kent Fredric
 
Default RFC: split up media-sound/ category

On 22 June 2011 21:38, Joshua Saddler <nightmorph@gentoo.org> wrote:
>
> Whatever happened to implementing tags for the Portage tree? The idea
> behind tags was to avoid spamming users with more and more
> directories, especially for apps that are hard to categorize. Which,

Agreed. From the perspective of what will need to happen with regard
to package moves, implementing this change is likely to be incredibly
disruptive to users, and possibly cause a few wtfs/cry fests. ( Worst
case scenario pessimism I admit ).

I'd love a tag solution, that'd be nice, is there a GLEP for it yet?
And if so, how long will it take to get this "tag" feature supported
by EAPI standards?

--
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-22-2011, 09:46 PM
Zac Medico
 
Default RFC: split up media-sound/ category

On 06/22/2011 02:38 AM, Joshua Saddler wrote:
> Whatever happened to implementing tags for the Portage tree? The idea
> behind tags was to avoid spamming users with more and more
> directories, especially for apps that are hard to categorize. Which,
> arguably, is most of them. We have tags for weblog content/topics;
> tags for ebuilds are also a good idea.

It could be implemented with a metadata.xml extension, or possibly an
new ebuild variable. A GLEP would be a good way to propose such an
extension.

> Splitting up the media-* categories doesn't solve any problems for
> the packages that do many different things, whether encoding,
> playing, editing, wrapping, connecting, etc. Many media apps belong
> in 3 or 4 or more categories. Tags are the right solution for these,
> rather than being pigeonholed into just one category, which only
> reflects one use.

I tend to agree that addition of more categories probably isn't very
useful. However, I wouldn't be opposed to people adding new categories
if they believe that it will be useful somehow.
--
Thanks,
Zac
 
Old 06-22-2011, 11:58 PM
Kent Fredric
 
Default RFC: split up media-sound/ category

On 23 June 2011 09:46, Zac Medico <zmedico@gentoo.org> wrote:

> It could be implemented with a metadata.xml extension, or possibly an
> new ebuild variable. A GLEP would be a good way to propose such an
> extension.

I'd myself see metadata.xml or ebuild variables, on their own, less
than useful.

For me, the primary benefit of the category system is it makes it easy
to locate and install packages I wish to install, and hidden metadata
stored in the package itself would prove very unhelpful in this
regard.

In order for this metadata to be of any use to a user, it would need
to have some way to facilitate its use, whether it be a fake generated
directory of symlinks, or a dedicated program ( like debians aptitude
) for exploring this data in a tag-oriented way.

( And any solution which requires software to iterate and index the
entirety of portage to accumulate this tag data, user side, will be
considerably unfavourable in my eyes )

--
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-23-2011, 12:41 AM
Zac Medico
 
Default RFC: split up media-sound/ category

On 06/22/2011 04:58 PM, Kent Fredric wrote:
> On 23 June 2011 09:46, Zac Medico <zmedico@gentoo.org> wrote:
>
>> It could be implemented with a metadata.xml extension, or possibly an
>> new ebuild variable. A GLEP would be a good way to propose such an
>> extension.
>
> I'd myself see metadata.xml or ebuild variables, on their own, less
> than useful.
>
> For me, the primary benefit of the category system is it makes it easy
> to locate and install packages I wish to install, and hidden metadata
> stored in the package itself would prove very unhelpful in this
> regard.

Of course, support would have to be integrated into search tools.

> In order for this metadata to be of any use to a user, it would need
> to have some way to facilitate its use, whether it be a fake generated
> directory of symlinks, or a dedicated program ( like debians aptitude
> ) for exploring this data in a tag-oriented way.
>
> ( And any solution which requires software to iterate and index the
> entirety of portage to accumulate this tag data, user side, will be
> considerably unfavourable in my eyes )

For example, we could extend egencache to generate an index of tags,
similar to how it generates use.local.desc from all of the metadata.xml
files.
--
Thanks,
Zac
 
Old 06-23-2011, 06:15 AM
Jess J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/23 Kent Fredric <kentfredric@gmail.com>:
> On 23 June 2011 09:46, Zac Medico <zmedico@gentoo.org> wrote:
>
> In order for this metadata to be of any use to a user, it would need
> to have some way to facilitate its use, whether it be a fake generated
> directory of symlinks, or a dedicated program ( like debians aptitude
> ) for exploring this data in a tag-oriented way.

The problem is that there's no official GUI for portage, and I don't
think we should have that either. 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 the user, it will be a convenient way to look into media-tv, and
find there all the tv players like kaffeine and mplayer that s/he
would not have found otherwise. Even portage managers like portato
will list the packages following the directory structure, so I think
we should concentrate on that, rather than doing fancy things that
won't be useful for a thousand years. Tags might be elegant, but I
don't think they are practical for the average Gentoo user, which
probably is the kind of user that sets USE="-semantic-desktop" to
avoid using the whole kde tagging system. I also don't know if the
advantages of tagging are really worth all the pain to implement. And
after that, every Gentoo user will have to learn a new way to interact
with portage when it comes to searching the package s/he needs.

--
Jess Guerrero Botella
 
Old 06-23-2011, 08:53 AM
Duncan
 
Default RFC: split up media-sound/ category

Jess J. Guerrero Botella posted on Thu, 23 Jun 2011 08:15:44 +0200 as
excerpted:

> Symlinks are clean, and portage has always been file-oriented so I see
> no problem with using them for this.

It has been some years since I've seen the argument made, but if I'm not
mistaken, at least back in 2004-ish when I first switched to Gentoo, the
argument against in-tree symlinking (or multi-hard-linking, for that
matter) of any kind (other than the obvious directory hard-linking) was
that we wanted to keep the tree at least minimally deployable on non-Unix
filesystems like fat/ntfs. Note that while a user's profile uses a
symlink, the symlink is on /etc (which is thus implied to be a Unix
filesystem with symlinking capacities) pointing /into/ the tree, NOT
actually PART OF the tree.

One scenario in which this might be a factor is that of someone doing
their syncs and source downloads at work where they have lots of
bandwidth available, then sneakernetting it home on a fat32 formatted
thumbdrive.

Now it can be argued that the flexibility benefit of multi-category
packages trumps that of being able to put the tree on fat or whatever,
but there IS a definite loss of tree portability that's implied, and thus
a tradeoff to be considered.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 06-23-2011, 09:08 AM
Jess J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/23 Duncan <1i5t5.duncan@cox.net>:
> Jess J. Guerrero Botella posted on Thu, 23 Jun 2011 08:15:44 +0200 as
> excerpted:
>
>> Symlinks are clean, and portage has always been file-oriented so I see
>> no problem with using them for this.
>
> It has been some years since I've seen the argument made, but if I'm not
> mistaken, at least back in 2004-ish when I first switched to Gentoo, the
> argument against in-tree symlinking (or multi-hard-linking, for that
> matter) of any kind (other than the obvious directory hard-linking) was
> that we wanted to keep the tree at least minimally deployable on non-Unix
> filesystems like fat/ntfs. *Note that while a user's profile uses a
> symlink, the symlink is on /etc (which is thus implied to be a Unix
> filesystem with symlinking capacities) pointing /into/ the tree, NOT
> actually PART OF the tree.
>
> One scenario in which this might be a factor is that of someone doing
> their syncs and source downloads at work where they have lots of
> bandwidth available, then sneakernetting it home on a fat32 formatted
> thumbdrive.
>
> Now it can be argued that the flexibility benefit of multi-category
> packages trumps that of being able to put the tree on fat or whatever,
> but there IS a definite loss of tree portability that's implied, and thus
> a tradeoff to be considered.

Yes, that's true. But it's also true that besides the symlinks, the
portage tree will be broken the same moment you put it into a fat
volume, because it will directly erase all the permissions and
ownership metadata. So, the thing is already broken, why should we
care if it breaks a bit more? Seriously, limiting ourselves because of
an fs that not even MS uses any longer is not a smart thing to do, in
my opinion.

--
Jess Guerrero Botella
 
Old 06-23-2011, 09:16 AM
Ciaran McCreesh
 
Default RFC: split up media-sound/ category

On Thu, 23 Jun 2011 11:08:35 +0200
Jess J. Guerrero Botella <jesus.guerrero.botella@gmail.com> wrote:
> But it's also true that besides the symlinks, the portage tree will
> be broken the same moment you put it into a fat volume, because it
> will directly erase all the permissions and ownership metadata.

Those don't matter to a package manager, beyond that they're readable
by every process. What does matter is mtimes.

--
Ciaran McCreesh
 
Old 06-23-2011, 10:31 PM
"Aaron W. Swenson"
 
Default RFC: split up media-sound/ category

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/22/2011 05:18 AM, Kent Fredric wrote:
> On 22 June 2011 08:37, Michał Górny <mgorny@gentoo.org> wrote:
>>> Right. mplayer, xine, etc, work just fine as for instance mp3
>>> players. So media-xxxx is fine for them.
>>
>> But probably we'll move it into media-players and so on then.
>
> mplayer and some other things most-often used for playback might be a
> bit of a hard-to-categorise subject though, ie: mplayer ships with
> mencoder, which is more editing spectrum. I'm lead to believe you can
> do some degree of transcoding with VLC too, but I might have a memory
> problem ( I recall reading something along those lines, but it may be
> "future tense" )
>
> incidentally, I'd be in favour of splitting mplayer and mencoder into
> seperate dists if it were sanely plausible to do so.
>
>
I'd venture that most people grab mplayer for its playback capabilities
more often than its ability to modify media.

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

iF4EAREIAAYFAk4Dvq4ACgkQCOhwUhu5AEk3DQD7B9rllKzVCB EHmclLmvIfF5jN
09s4pF9iqc6PVriDyPUA/i/jHmmjHxHc6tBq59Ao8jNI4aU4tuoxFDhmatCOxJcp
=m8pk
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 10:03 AM.

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