Re: Idea - schematic information in %description
Dnia czwartek, 3 maja 2007, Przemyslaw Iskra napisał: On Thu, May 03, 2007 at 08:57:40AM -0400, Jeff Johnson wrote: If you want package categories, please add as a separate tag, not by overloading description. Yup, that would be a better idea. I was thinking about %description because it actually works. Adding new tag requires some work in rpm, as well as a decent support in poldek. But making a list of all possible categories and tags, and than adding it to packages is going to take a lot of time anyway. I don't really feel the idea of adding such information separatelly from building process. Of course it isn't wise to rebuild some big package just because of changes in summary, description or category, but in case of our automation a lot of work may be required to do it other way than rebuilding the package. Maybe something like Provides: SUPPORT_extension which could be even autogenerated at build time from proper mime type description availible in most packages .desktop files? [EMAIL PROTECTED] ~]$ cat /usr/share/applications/gimp.desktop | grep MimeType MimeType=image/bmp;image/g3fax;image/gif;image/jpeg;image/jpg;image/pjpeg;image/png;image/tiff;image/x-bmp;image/x-compressed-xcf;image/x-fits;image/x-gray;image/x-pcx;image/x-png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-psd;image/x-sgi;image/x-sun-raster;image/x-tga;image/x-xbitmap;image/x-xcf;image/x-xpixmap;image/x-xwindowdump; and the appopriate XDG mime search? This could be a pretty nifty freedesktop spec ; Regards, -- Łukasz [DeeJay1] Jernaś signature.asc Description: This is a digitally signed message part. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Idea - schematic information in %description
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?
[EMAIL PROTECTED] ~]$ 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.
Anyway MimeType from .desktop files should be useful to get
preliminary information.
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.
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 | | _ \| | | : WWWppcrcd.pld-linux.org
\\| -_)'___| ||^'||//\\//| _/| | | : JID..sparkyatjabberes.org
(/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mailsparkyatpld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Idea - schematic information in %description
My proposal it to add some schematic (with well known structure)
information to %description in packages. That would allow to easyly
find some suitable application using search in poldek, or grep in
SPECS directory.
Teoretically rpm groups should be used for that prupose, but there
are very little different groups, and one application may not have
more than one group at once.
Additionally information I's like to be added would be mainly
(only ?) useful for applications, so there is no sense to play
with the groups.
The structure should be described in some file found in CVS, in
PLD-Doc or in SPECS directory, it should also contain as many
translations as possible, and some descriptions of each category,
it has to be human-readable.
I think it would look like:
openoffice.org-writer:
(blabla, old %description)
Edit: odt, ott, sxw, doc, (try to list all)
Save: odt, ott, sxw, doc, pdf, (try to list all)
gqview:
Open: bmp, png, jpeg (try to list all)
mplayer:
Open: avi, mpeg, wmv, mp3, ac3 (try to list all)
mencoder:
Convert: avi, mpeg, wmv, dvd, vcd
Save: avi, mpeg
In some cases additional, optional plugins would be required to get some
funcionality, that funcionality should be listed in main package anyway,
but in parentesis plugin name should be specified.
ImageMagick (convert):
Convert: png (coder-png), jpeg (coder-jpeg), (...)
Save: png (coder-png), jpeg (coder-jpeg), (...)
Other things than file manipulation:
quake3:
Game: fps; network
tremulous:
Game: fps, strategy; multiplayer-only, network
wesnoth:
Game: strategy; turn-based; network, hot-chair
My initial proposal of categories, it must be discussed, extended,
and made easy to understand (human readable):
[file types]
[graphics]
png - portable network graphics
jpeg
bmp
xcf - gimp file
[audio]
mp3
ogg vorbis
ac3
[video]
ogg - theora + (optionally) vorbis
avi - (should be split to divx, and others)
mpeg
[office]
odt - OpenDocument
ott - OpenDocument template
sxw - star/open office writer file
doc - m$ file
pdf
...
[categories]
Edit, [ca] Edita, [es] Edita, [pl] Edytuje:
(application is able to open file for editing and
manipulation)
keywords:
(file types)
Convert, [ca] Convertix, [es] Convierte, [pl] Konvertuje:
(able to open file for saving it as annother file type)
keywords:
(file types)
Open, [ca] Obri, [es] Abre, [pl] Otwiera:
(application is able to open file for displaying
or reproduction)
keywords:
(file types)
Save, [ca] Desa, [es] Guarda, [pl] Zapisuje:
(able to asve to that file type after manipulation
or when converting)
keywords:
(file types)
Game, [ca] Joc, [es] Juego, [pl] Gra:
(application is a game with following specifications)
keywords:
fps - first-person shooter
rpg - role-playing game
straregy, [ca] estrategia, [es] estrategia,
[pl] strategia
cards, [ca] cartes, [es] cartas, [pl] karty
(...)
turn-based
- turn based, if not specified it is real-time
- cards implies turn-based, no need to specify
multiplayer-only
- there is no possibility for single game
network, [ca] xarxa, [es] red, [pl] siec
- network multiplayer game
split-screen
- each player has it's own part of the screen
same-screen
- both players are visible on the same screen
hot-chair
- available in turn based games, player should
not know what the other is doing, if they are
allowed to see use same-screen (tictactoe?)
OK, that is only the proposal. Needs discussion. Similar categories
must be developed for other kinds of applications.
So, what do you think ?
--
Sparky{PI] -- Przemyslaw _ ___ _ _ ... LANG...Pl..Ca..Es..En
/) ___ ___ _ _ || Iskra | | _ \| | | : WWWppcrcd.pld-linux.org
\\| -_)'___| ||^'||//\\//| _/| | | : JID..sparkyatjabberes.org
(/|| (_-_|_|| ||\\ || |_ |_|
Re: Idea - schematic information in %description
If you want package categories, please add as a separate tag, not by overloading description. What really needs to be done is to attach a category hierarchy with, but not in, packaging. Rebuilding a package to change hierarchy is too burdensome. I can/will add a header extension tag to rpm for any reasonably designed format for hierarchical categories of packages. I suggest as a representation language YAML, but XML will work too. The connections betweeen the categories and packages should be specific enough to tag a single unique instance of a package using pkgid or hdrid, as well as broad enough to match all packages with same name. The hierarchy identifiers should be internationalized as well. hth 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Idea - schematic information in %description
On 5/3/07, Jeff Johnson [EMAIL PROTECTED] wrote: If you want package categories, please add as a separate tag, not by overloading description. Additionally, there is little to no sense to list file extensions as *NIX has no concept of extensions. Systems operate on MIME types. What really needs to be done is to attach a category hierarchy with, but not in, packaging. Rebuilding a package to change hierarchy is too burdensome. I agree but I see no real advantage of listing handled file types for each package. Expecially since package X might only support MIME type Y if Z is also installed or if manually configured to use V. -- Patryk Zawadzki Generated Content ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Idea - schematic information in %description
On May 3, 2007, at 11:56 AM, Przemyslaw Iskra wrote: On Thu, May 03, 2007 at 08:57:40AM -0400, Jeff Johnson wrote: If you want package categories, please add as a separate tag, not by overloading description. Yup, that would be a better idea. I was thinking about %description because it actually works. Adding new tag requires some work in rpm, as well as a decent support in poldek. But making a list of all possible categories and tags, and than adding it to packages is going to take a lot of time anyway. I'll be happy to do the rpm work. There is little additional poldek work if categories are added as a header extension tag. I don't really feel the idea of adding such information separatelly from building process. Of course it isn't wise to rebuild some big package just because of changes in summary, description or category, but in case of our automation a lot of work may be required to do it other way than rebuilding the package. You may not see the difference, but I certainly do. Every month someone is suggesting a new package organization and wishes to use or change some hierarchy or values. Category information *must* be outside of packaging so that users may rearrange the tag values and hierarchy to taste. Your suggestion is the 4th this year that I am aware of. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
