Idea - schematic information in %description

[Jeff Johnson]

On May 4, 2007, at 8:00 AM, Przemyslaw Iskra wrote:

> On Fri, May 04, 2007 at 01:35:28PM +0200, Łukasz Jernaś wrote:
>>
>> Maybe something like Provides: SUPPORT_<extension>
>
> I'd say: no. This has to be primatly information for people, not  
> scripts
> or for some automation.
>
>> which could be even
>> autogenerated at build time from proper mime type description  
>> availible in
>> most packages .desktop files?
>> [deejay1 at betty ~]$ cat /usr/share/applications/gimp.desktop | grep  
>> MimeType
>> MimeType=image/bmp;image/g3fax;image/gif;image/jpeg;image/jpg;...
>
> I was thinking about ripping information from .desktop files, but how
> about console applications without desktop file ? Like file converters
> and such. Or when some additional package is needed for that
> funcionality.
>

If you just want a marker for mime-type handlers that are currently
resident in a MimeType tag, then overloading dependencies with, say
     Provides: desktop(image/bmp;image/g3fax)
makes a lot of sense.

My previous comments where wrto Group: tag analogues. There's
a new suggestion for a Category: hierarchy monthly.

> Anyway MimeType from .desktop files should be useful to get
> preliminary information.
>

Look at existing libtool(...) or pkgconfig(...) automagic dependency
extraction scripts for examples.

>
> And supported file types is not the only thing I'd like to be tagged
> this way, but for now only other use for it I've got in my head is
> describing game generes.
>

FYI, rpm already classifies files using libmagic. It would not be hard
to run libmagic to automagically generate the mime-type associated
with every file, filter, and save in metadata.

What would be needed for a useful implementation is some thought
about where the mime-types for each file should be installed. An rpmdb
is rather too much work for most applications to retrieve data.

> So now, let's think where such tagging may be useful. Later we will
> think about the tags. And at the end about implementation. Because  
> there
> is no sense to think about implementation of something that does not
> exist.
>
> -- 
>  ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ...........  
> LANG...Pl..Ca..Es..En
> /____) ___  ___  _ _ || Iskra  |  | _ \| |  | :  
> WWW........ppcrcd.pld-linux.org
> \____\| -_)'___| ||^'||//\\// <   |  _/| |  | :  
> JID......sparky<at>jabberes.org
> (____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| :  
> Mail....sparky<at>pld-linux.org
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en