Re: [Cooker] naming policy
Götz Waschk [EMAIL PROTECTED] writes: order is OK, but this is a bit overregulation. I think it's better to stick to the original name if possible. Else people won't find a software in the distribution they are looking for and compile it themselves. The package ordering through the rpm groups should be sufficient. We're already not respecting that for perl modules for examples.. The drawback you describe is real but IMHO not enough compared to the consistency it brings. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] naming policy
On Sunday 27 July 2003 23:04, Andi Payn wrote: On Friday 25 July 2003 08:31, Michael Scherer wrote: Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam There are two important distinctions here that are being missed. First, adns-python and libxslt-python are python interfaces to the standalone packages adns and libxslt; python-xoltar is a standalone set of extensions to the python standard libraries (there is no xoltar package). Well, even if this is named python-adns, i guess that most people can deduce that it is related to libadns. The source of a package should not impact his name. Second, adns-python and libxslt-python come from the same tarball (or another tarball on the same project site) as adns and libxslt; python-xoltar is a project on its own. In other words, this is just like the difference between gimp-perl (the perl interface to gimp, distributed with gimp) and python-Inline (an extension to the perl standard libraries, distributed as Inline in CPAN). No, because the gimp-perl package is something that enhance gimp. adns-python enhance python, not libadns. I do not see the need to make a distinction between a module which is an interface, and a module written in pure python, not related to a C library. For a user point of view, there is no différences. So, if a package is a extension to a program, in order to add scripting capabilities in some language, i guess that program-language should be used. If not, if this is a module, language-module make more sense. The rule of thumb that perl packages seem to follow is: If the package's primary source is CPAN, the package is perl-Foo-Bar, where Foo::Bar is the CPAN name; if the primary source is the foo distribution,the package is foo-perl. Do we want to change this rule to always use the perl-Foo-Bar style of naming? Or is it better to just codify the existing de facto rule, and extend it to python (which would mean the vast majority of existing perl and python packages are already named correctly)? Well, at least, we should write the rule, whatever ti will turn to be. Note that python doesn't have a real equivalent to CPAN (for example, there's no Starship entry for xoltar, or cRat, or perlmodule). This also means that it's harder to figure out a canonical name for a package. If the Xoltar website has a tarball called xoltar which includes no files named xoltar, is the resulting package python-Xoltar or python-xoltar? If the CRat website has a tarball called cRat which builds a module called crat.so, is the package python-CRat, python-cRat, or python-crat? (For the modules I've packaged, I've used the name of the tarball.) What about to use the name of the import ? If the name is Xoltar, the problem of how we should name it is different from the problem of the position of 'python' in the name. I think that capitalized name of package are unpleasant to read, and, most people will use lowercase when searching so except for the pleasure of having the same name, this is , IMHO, useless. -- Michaël Scherer
Re: [Cooker] naming policy
On Mon Jul 28 9:17 +0200, Michael Scherer wrote: What about to use the name of the import ? If the name is Xoltar, the problem of how we should name it is different from the problem of the position of 'python' in the name. I think that capitalized name of package are unpleasant to read, and, most people will use lowercase when searching so except for the pleasure of having the same name, this is , IMHO, useless. However, I would suspect that a user who goes to the website of the program, decides, hey, that looks nice, would then attempt to download it with urpmi Programname (note the caps). Again, I think that explicit Provides: in such cases may be the best option... -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Corrosion of Conformity - Wiseblood - Bottom Feeder Linux 2.4.21-3mdk 03:38:00 up 1 day, 6:25, 8 users, load average: 0.76, 0.46, 0.32
Re: [Cooker] naming policy
On Friday 25 July 2003 08:31, Michael Scherer wrote: Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam There are two important distinctions here that are being missed. First, adns-python and libxslt-python are python interfaces to the standalone packages adns and libxslt; python-xoltar is a standalone set of extensions to the python standard libraries (there is no xoltar package). Second, adns-python and libxslt-python come from the same tarball (or another tarball on the same project site) as adns and libxslt; python-xoltar is a project on its own. In other words, this is just like the difference between gimp-perl (the perl interface to gimp, distributed with gimp) and python-Inline (an extension to the perl standard libraries, distributed as Inline in CPAN). The rule of thumb that perl packages seem to follow is: If the package's primary source is CPAN, the package is perl-Foo-Bar, where Foo::Bar is the CPAN name; if the primary source is the foo distribution,the package is foo-perl. Do we want to change this rule to always use the perl-Foo-Bar style of naming? Or is it better to just codify the existing de facto rule, and extend it to python (which would mean the vast majority of existing perl and python packages are already named correctly)? Note that python doesn't have a real equivalent to CPAN (for example, there's no Starship entry for xoltar, or cRat, or perlmodule). This also means that it's harder to figure out a canonical name for a package. If the Xoltar website has a tarball called xoltar which includes no files named xoltar, is the resulting package python-Xoltar or python-xoltar? If the CRat website has a tarball called cRat which builds a module called crat.so, is the package python-CRat, python-cRat, or python-crat? (For the modules I've packaged, I've used the name of the tarball.)
Re: [Cooker] naming policy
On Sun Jul 27 14:04 -0700, Andi Payn wrote: Second, adns-python and libxslt-python come from the same tarball (or another tarball on the same project site) as adns and libxslt; python-xoltar is a project on its own. Perhaps in this case, it may make sense to have the rpm named $STUFF-(perl|python) but have a Provides: (perl|python)-$STUFF... thus a urpmi python-adns would install adns-python. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Monster Magnet - God Says No - Heads Explode Linux 2.4.21-3mdk 00:34:00 up 1 day, 3:21, 8 users, load average: 0.16, 0.11, 0.14
Re: [Cooker] naming policy
This may not the right moment to discuss about this, but I think we should set up a naming policy for the rpm. To give a simple exemple, the python module. Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam i suggest to stick to python-bar form, in the same way that perl modules are named. Hi, order is OK, but this is a bit overregulation. I think it's better to stick to the original name if possible. Else people won't find a software in the distribution they are looking for and compile it themselves. The package ordering through the rpm groups should be sufficient. -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War
Re: [Cooker] naming policy
On Saturday 26 July 2003 14:28, Götz Waschk wrote: This may not the right moment to discuss about this, but I think we should set up a naming policy for the rpm. To give a simple exemple, the python module. Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam i suggest to stick to python-bar form, in the same way that perl modules are named. Hi, order is OK, but this is a bit overregulation. I think it's better to stick to the original name if possible. Else people won't find a software in the distribution they are looking for and compile it themselves. I suggested to prefix the original names. So, if a someone search, let's say, a python module named foo, a search on foo should give him python-foo. If not, this means that another software is already called foo, and so, this means we couldn't stick to the original name. The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). -- Michaël Scherer
Re: [Cooker] naming policy
Ainsi parlait Michael Scherer : The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). nope, urpmi TAB output is ordered too :-) -- Disks are always full. It is futile to try to get more disk space. Data expands to fill any void. -- Murphy's Computer Laws n°4
Re: [Cooker] naming policy
Ainsi parlait Götz Waschk : This may not the right moment to discuss about this, but I think we should set up a naming policy for the rpm. To give a simple exemple, the python module. Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam i suggest to stick to python-bar form, in the same way that perl modules are named. Hi, order is OK, but this is a bit overregulation. I think it's better to stick to the original name if possible. Else people won't find a software in the distribution they are looking for and compile it themselves. The package ordering through the rpm groups should be sufficient. We already use lowercase only for names, whereas many software use mixed case for their name. I also think all modules/libraries for a given language (as opposed to final software) should get prefixed such as python-foo, perl-bar, ocaml-baz, etc.. BTW, there has also been sugested that documentation package should get prefixed too by doc-. It would notably allow to change the current mdk lame package to doc-lame, and revert the plf notlame package to lame. -- The speed with which components become obsolete is directly proportional to the price of the component. -- Murphy's Computer Laws n°9
Re: [Cooker] naming policy
On Sat 26 Jul 2003 13:10, Guillaume Rousse posted as excerpted below: Ainsi parlait Michael Scherer : The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). nope, urpmi TAB output is ordered too :-) Doesn't that require bash-completion? And what about those using other shells? -- Duncan - List replies preferred. They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin
Re: [Cooker] naming policy
Duncan [EMAIL PROTECTED] wrote: On Sat 26 Jul 2003 13:10, Guillaume Rousse posted as excerpted below: Ainsi parlait Michael Scherer : The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). nope, urpmi TAB output is ordered too :-) Doesn't that require bash-completion? And what about those using other shells? Works fine in zsh :) What about replacing bash with zsh as the default shell? :) # Han -- http://www.xs4all.nl/~hanb/software http://www.xs4all.nl/~hanb/documents/quotingguide.html
Re: [Cooker] naming policy
Ainsi parlait Han Boetes : Duncan [EMAIL PROTECTED] wrote: On Sat 26 Jul 2003 13:10, Guillaume Rousse posted as excerpted below: Ainsi parlait Michael Scherer : The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). nope, urpmi TAB output is ordered too :-) Doesn't that require bash-completion? And what about those using other shells? Works fine in zsh :) What about replacing bash with zsh as the default shell? :) When it will be able to emulate bash completion correctly: [EMAIL PROTECTED] guillaume/audio/net # zsh /etc/bash_completion:53: command not found: shopt /etc/bash_completion:59: command not found: complete /etc/bash_completion:65: command not found: complete /etc/bash_completion:66: command not found: complete [..] -- The speed with which components become obsolete is directly proportional to the price of the component. -- Murphy's Computer Laws n°9
Re: [Cooker] naming policy
Guillaume Rousse [EMAIL PROTECTED] wrote: Ainsi parlait Han Boetes : Duncan [EMAIL PROTECTED] wrote: On Sat 26 Jul 2003 13:10, Guillaume Rousse posted as excerpted below: Ainsi parlait Michael Scherer : The package ordering through the rpm groups should be sufficient. But, the ordering is only accessible with rpmdrake ( easily accesible ). nope, urpmi TAB output is ordered too :-) Doesn't that require bash-completion? And what about those using other shells? Works fine in zsh :) What about replacing bash with zsh as the default shell? :) When it will be able to emulate bash completion correctly: [EMAIL PROTECTED] guillaume/audio/net # zsh /etc/bash_completion:53: command not found: shopt /etc/bash_completion:59: command not found: complete /etc/bash_completion:65: command not found: complete /etc/bash_completion:66: command not found: complete [..] no way, that's ugly :P # Han -- http://www.xs4all.nl/~hanb/software http://www.xs4all.nl/~hanb/documents/quotingguide.html
