Re: Pidgin in the tree ...
On Friday 04 of May 2007, Joshua wrote: > Just wondering: is anybody else working on committing the pidgin > 2.0beta7 release that obsoletes gaim to the build tree? I guess no one is working on that. > Or are we > holding off on that because of the weirdness with the .gaim directory? > Or maybe holding off until the official pidgin-2.0 release? Simply no one did pidgin.spec. Such things that you talk about never had any significance for cvs commits - cvs is for developing. > --Joshua -- Arkadiusz MiĆkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Pidgin in the tree ...
Just wondering: is anybody else working on committing the pidgin 2.0beta7 release that obsoletes gaim to the build tree? Or are we holding off on that because of the weirdness with the .gaim directory? Or maybe holding off until the official pidgin-2.0 release? --Joshua ___ 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
Re: Idea - schematic information in %description
On Thu, May 03, 2007 at 05:40:10PM +0200, Patryk Zawadzki wrote: > 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. I did not mean file extensions but some short names for its type. And for reproducing music noone is going to look for application with audio/mpeg support, but with mp3 support. File extensions suck, but everyone uses and knows them. > 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. " 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), (...) " -- Sparky{PI] -- Przemyslaw _ ___ _ _ ... LANG...Pl..Ca..Es..En /) ___ ___ _ _ || Iskra | | _ \| | | : WWWppcrcd.pld-linux.org \\| -_)'___| ||^'||//\\// < | _/| | | : JID..sparkyjabberes.org (/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mailsparkypld-linux.org ___ 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 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. -- Sparky{PI] -- Przemyslaw _ ___ _ _ ... LANG...Pl..Ca..Es..En /) ___ ___ _ _ || Iskra | | _ \| | | : WWWppcrcd.pld-linux.org \\| -_)'___| ||^'||//\\// < | _/| | | : JID..sparkyjabberes.org (/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mailsparkypld-linux.org ___ 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
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
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..sparkyjabberes.org (/|| (_-_|_|| ||\\ || |_ |_| |